TRANSACTIONAL DIAGNOSIS BLOCK

专利摘要:
transactional diagnostic block. when an abort of an operation occurs on a computer system, a determination is made as to whether the diagnostic information is to be stored in one or more transaction diagnostic blocks (tdbs). there are different types of transaction diagnostic blocks to accept diagnostic information, depending on the abort type and other considerations. as examples, there is a program-specified tdb in which information is stored if a valid address tdb is provided in a transaction to begin the instruction; tdb a program interrupt, which is stored at when the program is aborted due to an interrupt; and a tdb trap program, which is stored in an abort when an trap results.
公开号:BR112014031335B1
申请号:R112014031335-0
申请日:2012-11-22
公开日:2022-01-04
发明作者:Dan Greiner；Christian Jacobi；Timothy Slegel；Marcel Mitran
申请人:International Business Machines Corporation；
IPC主号:

专利说明:

Technical Field
[0001] The present invention relates, in general, to multiprocessing computing environments, and in particular, to transaction processing within such computing environments. background
[0002] An ongoing challenge in multiprocessor programming is that of updates to the same storage location by multiple central processing units (CPUs). Many instructions that update storage locations, including even simple logical operations like AND, do so with multiple accesses to the location. For example, first the storage location is fetched and then the updated result is stored back.
[0003] In order for multiple CPUs to securely update the same storage location, access to the location is serialized. An instruction, test, and instruction set, introduced with the S/360 architecture previously offered by International Business Machines Corporation, provided an interleaved upgrade of a storage location. Embedded updating means that, as observed by other CPU's and the input/output (I/O) subsystem (eg, the channel subsystem), all storage instruction access appears to occur atomically. Later, the S/370 architecture offered by International Business Machines Corporation introduced the Compare and SWAP and COMPARE double and SWAP statements that provide a more sophisticated means of performing interlaced updating, and allow the implementation of what is commonly known as a word of block (or semaphore). Recently added instructions have provided additional interlaced-upgrade capabilities, including Compare and SWAP and Clear, and Compare and SWAP and Store. However, all these instructions provide interleaving for only a single storage location.
[0004] More than complex program techniques may require interleaved updating of multiple storage locations, such as when adding an element to a doubly linked list. In such an operation, both a backward and forward pointer are appearing to be updated simultaneously, as observed by other CPUs and the I/O subsystem. In order to effect such a multiple location update, the program is forced to use a distinct, single point of serialization as a lock word. However, blocking words can provide a much further level of serialization than is required; for example, lock words can serialize an entire queue of millions of elements even though only two elements are being updated. The program can structure the data using finer grained serialization (for example, a hierarchy of lockpoints), but that presents additional problems, such as potential deadlock situations if the hierarchy is violated, and recovery problems if the program encounters an error while holding one or more locks or if the lock cannot be acquired.
[0005] In addition to the above, there are numerous situations in which a program may execute a sequence of instructions that may or may not result in an exception condition. If no exception condition occurs, then the program continues; however, if an exception is recognized, then the program can take corrective action to eliminate the exception condition. Java, as an example, can exploit the execution of the same, for example, the speculative execution, partial function of a coating, and/or the re-sequencing of null pointer verification.
[0006] In classic operating system environments, such as z/OS and its predecessors offered by International Business Machines Corporation, the program establishes a recovery environment to intercept any exception program conditions it may encounter. If the program does not trap the exception, the operating system normally ends up abnormally from the program of exceptions that the operating system is not prepared to handle. Establishing and exploiting such an environment is expensive and complicated. summary
[0007] The shortcomings of the prior art are addressed and advantages are provided by providing a computer program product to provide diagnostic information when the transaction is rolled back. The computer program product includes a computer readable storage medium readable by a processing circuit and storing instructions for execution by the processing circuit for performing a method. The method includes, for example, detecting by a processor an abort of a transaction, the transaction effectively delaying committing transactional stores to main memory until the completion of a selected operation; determine, by the processor, whether diagnostic information is to be stored in a transaction diagnostic block (TDB) based on the Abort; and based on the determination indicating the diagnostic information should be stored, store the diagnostic information in the transaction diagnostic block, the diagnostic information to include an aborted operation instruction address.
[0008] Methods and systems of one or more embodiments are also described and claimed herein.
[0009] Additional features and advantages are realized. Other embodiments and aspects are described in detail herein and are considered part of the claimed invention. Brief Description of Drawings
[0010] Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which: Figure 1 represents an embodiment of a computing environment; Figure 2A shows an example of a TRANSACTION Begin (TBEGIN) instruction; Figure 2B shows a more detailed embodiment of a TBEGIN instruction field of Figure 2A; Figure 3A shows an example of a constrained Transaction Begin (TBEGINC) instruction; Figure 3B represents a more detailed embodiment of a TBEGIN instruction field. TBEGINC instruction of figure 3A; Figure 4 represents an example of a Transaction End (TEND) instruction; Figure 5 represents an example of a Transaction Abort (T ABORT) instruction; Figure 6 represents an example of nested transactions; Figure 7 shows an example of a NONTRANS instructional storage (NTSTG); Figure 8 illustrates an example of an EXTRACT DEPTH SETTING OPERATION (ETND) instruction; Figure 9 represents an example of a diagnostic blocking operation; Figure 10 illustrates an example of reasons to abort , along with associated abort codes and condition codes; Figure 11 shows an embodiment of the logic associated with executing a TBEGINC instruction; Figure 12 represents an embodiment of the logic associated with executing a TBEGIN instruction; Figure 13 represents an embodiment of the logic associated with executing a TEND instruction; Fig. 14 represents an embodiment of the logic associated with transaction abort processing; Figure 15 represents an embodiment of the logic associated with selectively storing information in diagnostic plus one or transaction blocks; Figures 16A-16B show an example of inserting a queue element into a doubly linked list of queue elements; Figure 17 represents an embodiment of a computer program product; Figure 18 represents an embodiment of a central computer system; Figure 19 represents another example of a computer system; Figure 20 represents another example of a computer system comprising a computer network; Figure 21 represents an embodiment of various elements of a computer system; Figure 22A shows an embodiment of the execution unit of the computer system of fig. 21; Figure 22B shows an embodiment of the branch unit of the computer system of fig. 21; Figure 22C illustrates an embodiment of the load/storage unit of the computer system of fig. 21; Figure 23 represents an embodiment of an emulated host computer system. Detailed Description
[0011] According to one embodiment, a transactional execution (TX) facility is provided. This facility provides transactional processing for instructions, and in one or more embodiments, offers different modes of execution, as described below, as well as nested levels of transactional processing.
[0012] The transactional execution facility introduces a CPU state called the transactional execution (TX) mode. Following a CPU reset, the CPU is not in TX mode. The CPU enters TX mode by transaction BEGIN instructions. The CPU leaves TX mode by either (a) an ultra-peripheral TRANSACTION END instruction (more on interior and exterior below), or (b) the operation being aborted. While in TX mode, storage accessed by the CPU appears to be block concurrent as seen by other CPUs and the I/O subsystem. Storage accesses are either (a) used for storage when the transaction ends outermost without aborting (i.e., changes made to a cache or buffer local to the CPU are propagated and stored in real memory and visible to other processors ), or (b) discarded if the transaction is aborted.
[0013] Transactions can be nested. That is, while the CPU is in TX mode, it can perform another start instruction operation. The instruction that causes the CPU to enter TX mode is called the TRANSACTION Outermost BEGIN; Likewise, the program is said to be in full aperture operation. Subsequent executions of the BEGIN operation are called internal instructions; and the program is executing an internal transaction. The model provides a model-dependent minimum nesting depth and model-dependent maximum nesting depth. An extract statement TRANSACTION NESTING DEPTH returns the current thread level value, and in another embodiment, may return a maximum nesting depth value. This technique uses a model called "flattened nesting", in which an abort condition at any nesting depth causes all levels of the transaction to be aborted, and control is returned to the statement after the outermost transaction BEGIN.
[0014] During the processing of an operation, a transactional access made by one CPU is said to conflict with either (a) a transactional access or non-transactional access made by another CPU, or (b) a non-transactional access made by the processing subsystem. I/O, if both accesses are to any location within the same cache memory line, and one or both accesses is a store. In other words, for the order of transaction execution to be productive, the CPU is not to be observed doing transactional accesses until it commits. This programming model can be highly effective in certain environments; for example, updating a colon in a doubly linked list of one million elements. However, it can be less effective if there is a lot of transactional contention for the storage locations that are being accessed.
[0015] In a transactional execution model (herein referred to as an unconstrained transaction), when a transaction is aborted, the program may either attempt to re-throw the transaction in the hope that the abort condition is no longer present, or the program may "fall" to an equivalent non-transactional path. In another transaction execution model (herein referred to as a constrained operation), an aborted transaction is automatically rolled back by the CPU; in the absence of constraint violations, the transaction is constrained to the certainty of eventual completion.
[0016] When initiating a transaction, the program can specify various controls, such as (a) which general records are restored to their original contents if the transaction is aborted, (b) whether the transaction is authorized to modify the floating-point - register context, including, for example, floating point registers and the floating point control register, (c) whether the transaction is allowed to modify access registers (ARs), and (d) whether certain program exception conditions are to be prevented from causing an interruption. If an unconstrained transaction is aborted, various diagnostic information can be provided. For example, the outermost TBEGIN statement that initiates an unconstrained transaction might designate a transaction specified program diagnostic block (TDB). In addition, the TDB in the prefix area of the CPU or designated by host state description may also be used, if the transaction is aborted due to a program interrupt or a condition that causes interpretive execution to terminate, respectively.
[0017] Indicated above are various types of registers. These are explained in more detail here in detail. General registers can be used as accumulators for general arithmetic and logical operations. In one embodiment, each register contains 64 bit positions, and there are 16 general registers. General registers are identified by the numbers 0-15, and are designated by a four-bit R field in an instruction. Some instructions provide to address multiple general registers by having multiple R fields. For some instructions, the use of a specific general register is implied rather than explicitly designated by an R domain of the instruction.
[0018] In addition to their use as accumulators for general arithmetic and logic operations, 15 of the 16 general registers are also used as base address and index registers in address generation. In these cases, the registers are designated by a four-bit B field or X in the A instruction field. A value of zero in field B or X specifies that no base or index is to be applied, and thus general register 0 is not to be designated as containing a base address or index.
[0019] Floating point instructions use a floating point register set. The CPU 16 has floating point registers, in one embodiment. Floating-point registers are identified by the numbers 0-15, and are designated by a four-bit R field in floating-point instructions. Each floating-point register is 64 bits long and can contain either a short (32-bit) or a long (64-bit) floating-point operand.
[0020] A floating point control (FPC) register is a 32-bit register that contains the mask bits, flag bits, a data exception code, and rounding mode bits, and is used when processing point operations. floating.
[0021] Furthermore, in one embodiment, the CPU 16 has control registers, each having 64-bit positions. Bit positions in registers are assigned to certain facilities in the system, such as program recording of the event (PER) (discussed below), and are used either to specify that an operation can take place or to provide special information required by the facility. . In one embodiment, for transaction setup, CR0 (bits 8 and 9) and CR2 (bits 61-63) are used, as described below.
[0022] The CPU has, for example, 16 access registers numbered 0-15. An access register consists of 32-bit positions containing an indirect specification of an address space control element (ASCE). An address space control element is a parameter used by the dynamic address translation (DAT) engine to translate references to a corresponding address space. When the CPU is in a register access mode call mode (controlled by bits in the program status word (PSW)), a B instruction field, used to specify a logical address for a storage operand reference, designates a register access, and the address space control element specified by the access register is used by DAT for reference. For some instructions, an R field is used instead of a B field. Instructions are provided for loading and storing the contents of the access registers and for moving the contents from one access register to another.
[0023] Each of access registers 1-15 can designate any address space. Register access 0 designates the primary instruction space. When one of access registers 1-15 is used to designate an address space, the CPU determines which address space is designated by translating the contents of the access register. When access register 0 is used to designate an address space, the CPU treats the access register as designating the primary instruction space, and does not examine the actual contents of the access register. Therefore, the access registers 16 can designate, at any one time, the primary instruction space and a maximum of 15 other spaces.
[0024] In one embodiment, there are several types of address spaces. An address space is a sequence of consecutive integers (virtual addresses), together with specific transformation parameters, that allow each number to be associated with a byte location of storage. The sequence starts at zero and amounts left to right.
[0025] In, for example, z/Architecture, when a virtual address is used by a CPU to access main storage (aka, main memory), it is converted first, via dynamic address translation (DAT). ), to a real address, and then, via a prefix, to an absolute address. DAT can use one to five levels of tables (page, segment, region third, region second, and region first) as transformation parameters. The designation (origin and length) of the top-level table for a specific address space is called an address space control element, and is found to be used by DAT in a control register or as specified by a control register. access. Alternatively, the address space control element for an address space may be a real space designation, which indicates that the DAT is translating virtual addresses simply by treating it as a real address and without using any tables.
[0026] DAT uses, at different times, the address space control elements in different control registers or specified by access registers. The choice is determined by the mode specified in the current PSW translation. Four translation modes are available: primary space mode, secondary space mode, access log mode and home space mode. Different address spaces are addressable depending on the translation mode.
[0027] At any time when the processor is in primary space mode or secondary space mode, the CPU can translate the virtual addresses that belong to two address spaces - the primary address space and the second address space. At any time when the CPU is in access register mode, it can translate the virtual addresses of up to 16 address spaces - the main address space and up to 15 AR address spaces - specified. Any time the processor is in home space mode, it can translate the virtual addresses from the home address space.
[0028] The primary address space is identified as such because it consists of primary virtual addresses, which are translated through the primary address space control element (ASCE). Likewise, the secondary address space consists of secondary virtual addresses translated through the secondary ASCE; the specified address spaces consist of the specified AR of the virtual addresses translated through the specified AR ASCES; and the home address space consists of Home virtual addresses translated through the home ASCE. The primary and secondary ASCES are in control registers 1 and 7, respectively. AR specified ASCES are in ASN-second table entries that are located through a process called access register translation (ART), using control registers 2, 5 and 8. The ASCE box is in control register 13.
[0029] An embodiment of a computing environment to incorporate and utilize one or more aspects of the transaction facility described here is described with reference to Figure 1.
[0030] Referring to Figure 1, in one example, the computing environment 100 is based on z/Architecture, offered by International Business Machines (IBM) Corporation, Armonk, New York. The z/Architecture is described in a publication entitled IBM "z/Architecture - Principles of Operation," Publication No. SA22-7932-08, 9th Edition, August 2010, which is incorporated herein by reference in its entirety.
[0031]Z / ARCHITECTURE, IBM, and Z/OS and z/VM (listed below) are registered trademarks of International Business Machines Corporation, Armonk, New York. Other names used herein may be registered trademarks, trademarks or product names of International Business Machines Corporation or other companies.
[0032] As an example, the computing environment 100 includes a central processor complex (CPC) 102 coupled to one or more input/output (I/O) 106 through one or more complex control units 108. The processor central 102 includes, for example, one or more central processors 110, one or more partitions 112 (e.g., logical partitions (LP)), a logical partition hypervisor 114, and an input/output subsystem 115, each one of which is described below.
[0033] Central 110 processors are physical processor resources assigned to logical partitions. In particular, each logical partition 112 has one or more logical processors, each of which represents all or a part of a physical processor 110 allocated to the partition. The logical processors of a specific partition 112 may be either dedicated to the partition, so that the underlying processor resource 101 is reserved for that partition; or shared with another partition, so that the underlying processor resource is potentially available to another partition.
[0034] A logical partition functions as a separate system and has one or more applications, and optionally, an operating system residing on it, which can be different for each logical partition. In one embodiment, the operating system is the z/OS operating system, the z/VM operating system, the z/Linux operating system, or the TPF operating system, offered by International Business Machines Corporation, Armonk, New York.
[0035] Logical partitions 112 are managed by a logical partition hypervisor 114, which is implemented by firmware running on processors 110. As used herein, firmware includes, for example, the microcode and/or millicode of the processor. It includes, for example, the hardware-level instructions and/or data structures used in implementing higher-level machine code. In one embodiment, it includes, for example, proprietary code that is typically delivered as microcode that includes hardware-specific software or site microcode and system access operation controls for the underlying system hardware.
[0036] The logical partitions and hypervisor Each logical partition comprises one or more programs residing in the respective central storage partitions associated with the central processors. An example of a logical partition 114 hypervisor is the Processor/System Manager (PR/SM) feature, offered by International Business Machines Corporation, Armonk, New York.
[0037] Input/output of a 15 subsystem directs the flow of information between input/output devices 106 and main storage (aka, main memory). It is coupled to the central processing complex in that it can be a part of the central processing complex or separate from them. The I/O subsystem relieves central processors of the task of communicating directly with input/output devices and allows data processing to proceed concurrently with input/output processing. To provide communications, the I/O subsystem uses I/O communication adapters. There are several types of communication adapters, including, for example, channels, I/O adapters, PCI cards, Ethernet cards, small computer storage interface (SCSI) cards, etc. In the particular example described here, the I/O communication adapters are channels and therefore the I/O subsystem is referred to herein as a channel subsystem. However, this is just an example. Other types of I/O subsystems can be used.
[0038] The I/O subsystem uses one or more input/output paths as communication links in managing the flow of information to or from input/output devices 106. In this particular example, these paths are called input paths. channel, since communication adapters are channels.
[0039] The computing environment described above is just an example of a computing environment that can be used. Other environments, including but not limited to, non-partitioned environments, other partitioned environments, and/or emulated environments, may be used; realizations are not limited to any one environment.
[0040] In one or more aspects, transactional execution ease is a CPU enhancement that provides the means by which the CPU can execute a sequence of instructions - known as a transaction - that can access multiple storage locations, including updating these locations. As noted by other CPUs and the I/O subsystem, the operation is either (a) completed in its entirety as a single atomic operation, or (b) aborted, potentially leaving no evidence that it ever performed (with the exception of certain conditions described here). Thus, a successfully completed operation can update multiple storage locations without any special locking that is required in the classic multiprocessing model.
[0041] Transactional execution facility includes, for example, one or more controls; one or more instructions; transactional processing, including restricted and unrestricted execution; and stopping processing, each of which is further described below.
[0042] In one embodiment, three special-purpose controls, including a Transaction Abort Program Status Word (PSW), a Transaction Diagnostic Block Address (TDB), and a Transaction Settlement Depth; five bits of the control register; and six general statements, including BEGIN TRANSACTION (constrained and nonconstrained), END TRANSACTION, SETTLEMENT OPERATION EXTRACT DEPTH, ABORT TRANSACTION, and NONTRANS ACTIONAL STORE, are used to control the transactional execution facility. When installation is installed, which is installed, for example, on all CPUs in the configuration. An indication of installation, bit 73 In one embodiment, when one, indicates that the transaction execution installation is installed.
[0043] When the transaction execution facility is installed, the configuration provides an unconstrained transactional execution facility, and, optionally, a constrained transactional execution facility, each of which is described below. When indications facilities 50 and 73, as examples, are both one, the constrained transactional execution facility is installed. Both installation indications are stored in memory in specific locations.
[0044] As used herein, the instruction name BEGIN TRANSACTION refers to the mnemonic TBEGIN (Transaction Begin for an unconstrained transaction) and TBEGINC (Transaction Begin for a constrained transaction) listen instructions. Discussions referring to a specific instruction are indicated by the instruction name followed by the accelerator in parentheses or brackets, or simply by the accelerator.
[0045] An embodiment of a format of a BEGIN operation (TBEGIN) of instructions is represented in figures 2A-2B. As an example, a TBEGIN instruction 200 includes an opcode field 202, which includes an opcode specifying an unrestricted start operation; a base field (Bi) 204; a displacement field (Di) 206; and an immediate field (I2) 208. When the Bi field is non-zero, the contents of the general register specified by the BI 204 are added in Di 206 to obtain the first address of the operand.
[0046] When the Bi field is non-zero, the following applies:
[0047] When the transaction nesting depth is initially zero, the first address of the operand designates the location of the transaction byte diagnostic block 256, called the TBEGIN-specified TDB (described later), in which various diagnostic information can be stored, if the transaction is aborted. When the CPU is in access mode or primary register space mode, the first address of the operand designates a location in the primary address space. When the CPU is in secondary space or home space mode, the first address operand designates a location in secondary space or home address, respectively. When DAT is off, the diagnostic block (TDB) TDBA transaction address) designates a location in actual storage.
[0048] Store accessibility to the first operand is determined. If accessible, the logical address of the operand is placed in the diagnostic transaction address block (TDBA), and the TDBA is valid.
[0049] When the CPU is already in unconstrained transactional execution mode, the TDBA is not modified, and it is unpredictable if the first operand is tested for accessibility.
[0050] When the Bi field is zero, no access exceptions are detected for the first operand, and for the outermost TBEGIN instruction, the TDBA is invalid.
[0051] The I2 field bits are set as follows, in an example:
[0052] General Register Save Mask (GRSM) 210 (figure 2B): Bits 0-7 of field I2 contain the register save general mask (GRSM). Each bit of the GRSM represents an even-odd pair of general registers, where 0 represents little registers 0 and 1, 1 bit represents registers 2 and 3, and so on. When a bit in the GRSM of the outermost TBEGIN instruction is zero, the corresponding register pair is not saved. When the bit in the GRSM of the outermost TBEGIN instruction is one, the corresponding register pair is saved in a location dependent model that is not directly accessible by the program.
[0053] If the transaction is aborted, saved register pairs are restored to their contents when the outermost TBEGIN instruction was executed. The contents of all other (unsaved) general records are not restored when the transaction is aborted.
[0054] General mask saving log is ignored in all TBEGINs except for the outside.
[0055] Allow AR Modification (A) 212: A A control, bit 12 of the I2 field, controls whether the transaction is allowed to modify an access register. The effective enabler of the AR modification control is the AND logic of the A control in the TBEGIN instruction for the current nesting level and for all outer levels.
[0056] If the effective A control is zero, the transaction will be aborted with code abort 11 (restricted instruction) if an attempt is made to modify any access register. If the effective A control is one, the transaction will not abort if an access record is modified (absent any other abort condition).
[0057] Allow Floating Point Operation (F) 214: Control F, bit 13 of the I2 field, controls whether the transaction is allowed to execute specified floating point instructions. The effective enable control floating point operation is the AND logic of the F control in the TBEGIN instruction for the current nesting level and for all outer levels.
[0058] If effective control F is zero, then (a) the operation will be aborted with interrupt code 11 (restricted instruction) if an attempt is made to execute a floating point instruction, and (b) the exception code data (DXC ) in byte 2 of the floating point control register (FPCR) will not be set by any data exception program exception condition. If the effective control F is one, then (a) the operation will not abort if an attempt is made to execute a floating-point instruction (in the absence of any other abort condition), and (b) the DXC in FPCR can be defined by an exception condition program data exception.
[0059] Program Interrupt Filtering Control (PIFC) 216: Bits 14-15 of field I2 are the program interrupt filtering control (PIFC). Financial control controls whether certain classes of program exception conditions (e.g., handling exception, data exception, operation exception, exception protection, etc.) that occur while the CPU is in execution mode transactional result in a interruption.
[0060] Effective public finance control is the highest public finance control value in the TBEGIN instruction for the current nesting level and for all external levels. When the effective PIFC is zero, all program exception conditions result in an interrupt. When the effective PIFC is only one, exception conditions program having a transactional execution class of 1 and 2 result in an interrupt. (Each program exception condition is assigned at least one transactional execution class, depending on the severity of the exception. Severity is based on the probability of recovery during repeated execution of the transaction execution, and whether the operating system has to see the interrupt ). When the effective PIFC is two, exception conditions program with a class transactional execution of a result in an interrupt. A public financial control of 3 is reserved.
[0061] Bits 8-1 1 of the I2 field (bits 40-43 of the instruction) are reserved and must contain zeros; otherwise, the program may not work compatibility in the future.
[0062] An embodiment of a format of a restricted Begin Operation (TBEGINC) instruction is described with reference to Figures 3A-3B. In one example, TBEGINC 300 includes an opcode field 302, which includes an opcode specifying a start operation restricted operation; a base field (Bi) 304; a shift field (Di) 306; and an immediate field (I2) 308. The contents of the general register specified by BI 304 are added in Di 306 to obtain the first address of the operand. However, with the transaction start constrained instruction, the first operand address is not used to access the storage. Instead, the Bi field of the instruction includes zeros; otherwise, a specification exception is recognized.
[0063] In one embodiment, field I2 includes several controls, an example of which is shown in Figure 3B.
[0064] The I2 field bits are set as follows, in an example:
[0065] General Register Save Mask (GRSM) 310: Bits 0-7 of field I2 contain the general register save mask (GRSM). Each bit of the GRSM represents an even-odd pair of general registers, where 0 represents little registers 0 and 1, 1 bit represents registers 2 and 3, and so on. When a bit in GRSM is zero, the corresponding record pair is not saved. When a bit in GRSM is one, the corresponding record pair is saved in a model-dependent location that is not directly accessible by the program.
[0066] If the transaction is aborted, saved register pairs are restored to their contents when the ultra peripheral OPERATION start instruction has been executed. The contents of all other (unsaved) general logs are not restored when a restricted transaction aborts.
[0067] When TBEGINC is used to continue execution in unrestricted transaction execution mode, the general save mask register is ignored.
[0068] Allow AR Modification (A) 312: A A control, bit 12 of the I2 field, controls whether the transaction is allowed to modify an access register. The effective control allow-AR modification is the AND logic of the A control in the TBEGINC instruction to the current nesting level and to any outer TBEGIN or TBEGINC instructions.
[0069] If the effective A control is zero, the transaction will be aborted with abort code 11 (restricted instruction) if an attempt is made to modify any access register. If the effective A control is one, the transaction will not abort if an access record is modified (absent any other abort condition).
[0070] Bits 8-1 1 and 13-15 of the I2 field (bits 40-43 and 45-47 of the instruction) are reserved and must contain zeros.
[0071] In order for a transaction to begin instruction is specified by a Transaction END (TEND) instruction, a format of which is represented in figure 4. As an example, a TEND 400 instruction includes a 402 opcode field, which includes an opcode specifying a transaction end operation.
[0072] A number of terms are used with respect to the ease of executing transactions, and therefore, for convenience only, a list of terms is provided below in alphabetical order. In one embodiment, these terms have the following definition:
[0073] Abort: A transaction aborts when it ends before an END TRANSACTION statement that results in a transaction nesting depth of zero. When a transaction is aborted, the following occurs in one embodiment:
[0074] • Transactional store accesses made by any and all levels of the transaction are discarded (ie, not committed).
[0075] Non-transactional store accesses made by any and all levels of the transaction are compromised.
[0076] Registers designated by the general register save mask (GRSM) of the ultra-peripheral BEGIN TRANSACTION instruction are restored to their contents before transactional execution (that is, to their contents when the outermost transaction starts the instruction). General does not register designated by the Address Book of economy mask of the outermost transaction start statement are not restored.
[0077] Access registers, floating point registers, and the floating point control register are not restored. Any changes made to these records during transaction execution are retained when the transaction is rolled back.
[0078] A transaction can be aborted due to a variety of reasons including attempted execution of a constrained instruction, attempted modification of a constrained resource, transactional conflict, overcoming multiple CPU resources, any execution interpretive intercept condition, any interrupt, an abort transaction statement, and other reasons. A transaction-abort code provides specific reasons why a transaction might abort.
[0079] An example of a format of a transaction abort (t abort) instruction is described with reference to Figure 5. As an example, a TABORT 500 instruction includes an opcode field 502, which includes an opcode specifying an operation abort operation; a base field (B2) 504; and a shift field (D2) 506. When field B2 is non-zero, the contents of the general register covered by B2 504 are added to 506 D2 to obtain a second address of the operand; otherwise, the second address of the operand is formed exclusively from the D2 domain, and the B2 field is ignored. The second address of the operand is not used for sending data; instead, addresses forms the transaction's abort code that is placed in a transaction diagnostic block during abort processing. Address computation for the second operand address follows the rules of address arithmetic: in 24-bit addressing mode, bits 0-29 are set to zeros; in bit 31 addressing mode, bits 0-32 are set to zero.
[0080] Commit: On completion of an ultra-peripheral TRANSACTION END instruction, the CPU commits the storage accesses made by the transaction (i.e., the outermost transaction and any nested levels) in such a way that they are visible to other CPUs and the I/O subsystem. As noted by other CPUs and the I/O subsystem, all fetch and store accesses made by all nested levels of the transaction appear to occur as a single concurrent operation occurs when committing.
[0081] The contents of general registers, access registers, floating point registers, and the floating point control register are not modified by the commit process. Any changes made to these records during transactional execution are retained when the transaction stores are compromised.
[0082] Conflict: A transactional access performed by a CPU conflict with (a) a transactional access or non-transactional access made by another CPU, or (b) non-transactional access made by the I/O subsystem, if both hits are to any location within the same cache line, and one or more of the hits is a store.
[0083] A conflict can be detected by speculatively executing a CPU of instructions, even though the conflict cannot be detected in the conceptual sequence.
[0084] Constrained transaction: A constrained transaction is a transaction that runs in constrained transactional execution mode and is subject to the following limitations:
[0085] A subset of the general instructions is available.
[0086] A limited number of instructions can be executed.
[0087] A limited number of operand storage locations can be accessed.
[0088] • Transaction is limited to a single nesting level.
[0089] In the absence of repeated interrupts or conflicts with other CPUs or the I/O subsystem, a constrained transaction eventually completes, thus an abort-handler routine is not necessary. Restricted operations are described in detail below.
[0090] When a transaction constrained BEGIN instruction (TBEGINC) is executed while the CPU is already in unconstrained transaction execution mode, execution continues as a nested unconstrained transaction.
[0091] Restricted Transactional Execution Mode: When the transaction nesting depth is zero, and a transaction is started by a TBEGINC instruction, the CPU enters the restricted transactional execution mode. While the CPU is in constrained transactional execution mode, the transaction nesting depth is one.
[0092] Nested transaction: When the transaction BEGIN instruction is issued while the CPU is in unconstrained transactional execution mode, the transaction is nested.
[0093] The transactional execution facility uses a model called flattened nesting. In flat-nesting mode, stores made by an inner transaction are not observable by other CPUs and the I/O subsystem until the outermost transaction commits its stores. Likewise, if a transaction is aborted, all nested transactions abort, and all transactional stores for all nested transactions are discarded.
[0094] An example of nested transactions is represented in figure 6. As shown, a first TBEGIN 600 starts an outermost transaction 601, TBEGIN 602 starts a first nested transaction, and TBEGIN 604 starts a second nested transaction. In this example, TBEGIN 604 and TEND 606 define an innermost transaction 608. When TEND 610 executes, transactional stores are committed 612 to the outermost transaction and all inner transactions.
[0095] Unconstrained transaction: An unconstrained transaction is a transaction that runs in unconstrained transactional execution mode. Although an unconstrained transaction is not limited to the way a constrained transaction is, it can still be aborted due to a variety of causes.
[0096] Unconstrained Transactional Execution Mode: When a transaction is started by the TBEGIN instruction, the CPU enters nonconstrained transactional execution mode. While the CPU is in nonconstrained transactional execution mode, the transaction nesting depth can vary from one to the maximum transaction nesting depth.
[0097] Non-transactional Access: Non-transactional accesses are operating storage accesses made by the CPU when it is not in transactional execution mode (ie, classic storage accesses outside of a transaction). Furthermore, the accesses made by the I/O subsystem are non-transactional accesses. Additionally, non-transactional storage instruction can be used to cause non-transactional storage access while the CPU is in unconstrained transactional execution mode.
[0098] One embodiment of a format for a non-transactional store instruction is described with reference to Figure 7. As an example, a non-transactional STORE 700 instruction includes a plurality of opcode fields 702a, 702b, specifying an opcode that designates a non-transactional store operation; a register field (Ri) 704 specifying a register, the contents of which are called the first operand; an index field (X2) 706; a base field (B2) 708; a first offset field (DL2) 710; and a second shift field (DH2) 712. The contents of the general registers designated by the fields X2 and B2 are added to the contents of a concatenation of the contents of the fields DH2 and DL2 to form the second address of the operand. When one or both of the X2 or B2 fields are equal to zero, the corresponding record does not participate in the addition.
[0099] The first 64-bit operand is placed non-transactionally unchanged in the second local operand.
[0100] The offset, formed by concatenating the DL2 and DH2 fields, is treated as a 20-bit binary signed integer.
[0101] The second operand must be aligned on a double word boundary; otherwise, specification exception is recognized and the operation is suppressed.
[0102] Outer / Outermost Transaction: A transaction with a lower transaction nesting depth is an external transaction. The transaction with a transaction nesting depth value of one is the outermost transaction.
[0103] An outermost transaction start statement is one that is executed when the transaction nesting depth is initially zero. An outermost END TRANS ACTION statement is one that causes the transaction nesting depth to transition from one to zero. An operation is restricted to the outermost operation in this embodiment.
[0104] Program Interrupt Filtering: When a transaction is aborted due to certain program exception conditions, the program can optionally prevent the interrupt from occurring. This technique is called program interrupt filtering. Program interrupt filtering is subject to the transactional class of the interrupt, effective program interrupt control filtering of the transaction start instruction, and program execution transactional interrupt filtering override in control register 0.
[0105] Transaction: Transaction includes storing operand accesses made, and general selected registers changed, while CPU is in transaction execution mode. For an unconstrained transaction, operand storage accesses can include both transactional accesses and non-transactional accesses. For constrained operation, operand storage accesses are limited to transactional accesses. As noted by other CPUs and the I/O subsystem, all storage-operating accesses made by the CPU while in transaction execution mode appear to occur as a single concurrent operation. If a transaction is aborted, transactional store accesses are discarded, and any registers designated by the general register save mask of the transaction's outermost BEGIN instructions are restored to their content prior to transactional execution.
[0106] Transactional Access: Transactional accesses are operating storage accesses made while the CPU is in transactional execution mode, with the exception of accesses made by the non-transactional storage instruction.
[0107] Transactional Execution Mode: The term transactional execution mode (aka, the transaction execution mode) describes the common operation of both the unrestricted and constrained transactional execution modes. Thus, when the operation is described, the terms unrestricted and restricted are used to qualify the transactional execution mode.
[0108] When the transaction nesting depth is zero, the CPU is not in transactional execution mode (also called non-transactional execution mode).
[0109] As noted by the CPU, fetches and stores done in transactional execution mode are no different than those done while not in transactional execution mode.
[0110] In one embodiment of the z/Architecture, the transactional execution facility is under the control of bits 8-90 of the control register, bits 61-63 of the control register 2, the transaction nesting depth, the transaction diagnostic block address, and the program status word abort transaction (PSW).
[0111] Following an initial CPU reset, the contents of register 0 control bit positions 8-9, register 2 control bit positions 62-63, and the transaction nesting depth are set to zero. When transactional execution control, 8 bits of register 0 control, is zero, the CPU cannot be put into transactional execution mode.
[0112] Further details on the various controls are described below.
[0113] As indicated, the transactional execution facility is controlled by two register zero control bits and three register two control bits. For example:
[0114] Control Register 0 Bits: The bit assignments are as follows, in one embodiment:
[0115] Transactional Execution Control (TXC): Control register bit 8 zero is transactional execution control. This bit provides a mechanism by which the controlling program (eg, operating system) can indicate whether or not the transaction execution facility is usable by the program. Bit 8 is to be one to successfully enter transactional execution mode.
[0116] When bit 8 of register control 0 is zero, attempt to execute extract DEPTH SETTLEMENT OPERATION, transaction BEGIN and edge transaction instructions results in a special operation execution.
[0117] An embodiment of a format of a SETTLEMENT DEPTH instruction TRANSACTION EXTRACT is described with reference to figure 8. As an example, an extract OPERATION FROM SETTLEMENT DEPTH 800 instruction includes an opcode 802 field specifying an opcode that indicates the operation extraction transaction nesting depth; and a register field R1 804 which designates a general register.
[0118] The current transaction nesting depth is placed in bits 48-63 of the general register Ri. Bits 0-31 of the register remain unchanged, and bits 32-47 of the register are set to zero.
[0119] In another embodiment, the maximum depth nesting operation is also placed in the general register Ri, such as in bits 16-31.
[0120] Execution Transaction Program Interrupt Filtering Override (Pifo): Zero register control bit 9 is the interrupt of the execution program transactional filtering override. This bit provides a mechanism by which the control program can guarantee that any program exception condition that occurs while the CPU is in transactional execution mode results in an interrupt, regardless of program interrupt filtering for duration specified or implied by the transaction BEGIN statement(s).
[0121] 2-Bit Register Control: The assignments are as follows, in one embodiment:
[0122] Transaction Diagnostic Scope (TDS): Bit 61 of the control register 2 controls the applicability of the Transaction Diagnostic Control (TDC) in bits 62-63 of the register, as follows:
[0123] TDS Value Meaning 0 TDC is applicable regardless of whether the CPU is in trouble or supervisor state. TDC 1 only applies when the processor is in trouble state. When the CPU is in supervisor state, processing is as if the TDC contained zero.
[0124] Transaction Diagnostic Control (TDC): Control register bits 62-63 is a two-bit unsigned integer that can be used to cause transactions to abort randomly for diagnostic purposes. The TDC encoding is as follows, in an example:
[0125] TDCValue Meaning0 Normal operation; operations are not aborted as a result of TDC.1 Abort each transaction in a random instruction, but before the execution of the outermost TRANSACTION END instruction.2 Abort random operations in a random instruction.3 Reserved
[0126] When a transaction aborts due to a non-zero TDC, then either the following can occur:
[0127] • Interrupt code is defined as any one of codes 7-11, 13-16, or 255, with the code value chosen at random by the CPU; the condition code is set corresponding to the abort code. Abort codes are additionally described below.
[0128] • For an unconstrained transaction, the condition code is set to one. In this case, the interrupt code is not applicable.
[0129] It is dependent on whether the TDC value 1 is implemented in the model. If not implemented, a value of 1 acts as if 2 was specified.
[0130] For a restricted operation, a TDC value of 1 is treated as if a TDC value of 2 was specified.
[0131] If a value of 3 TDC is specified, the results are unpredictable.
[0132] Diagnostic Transaction Address Block (TDBA)
[0133] The valid transaction diagnostic block address (TDBA) is set from the first operand address of the outermost transaction BEGIN (TBEGIN) instruction when the Bi field of the instruction is non-zero. When the CPU is in access register or main space mode, the TDBA designates a location in the main address space. When the CPU is in secondary space, or home space mode, the TDBA designates a secondary space location or home address, respectively. When DAT (Dynamic Address Translation) is off, the TDBA designates a location in actual storage.
[0134] The TDBA is used by the CPU to find the transaction diagnostic lock - the so-called TDB-specified TBEGIN - if the transaction is later aborted. The rightmost three bits of the TDBA are equal to zero, which means that the TDB-TBEGIN is specified on a doubleword boundary.
[0135] When the Bi field of an outermost transaction BEGIN (TBEGIN) instruction is zero, the transactional diagnostic block address is invalid and not specified by the TBEGIN TDB is stored if the transaction is later aborted.
[0136] Transaction Abort PSW (TAPSW)
[0137] During the execution of the BEGIN (TBEGIN) instruction when the nesting depth is initially zero, the transaction abort PSW is set to the contents of the current PSW; and the address of the PSW abort operation instruction designates the next sequential instruction (that is, the instruction following the outermost TBEGIN). During execution of the constrained BEGIN TRANSACTION (TBEGINC) instruction, when the nesting depth is initially zero, the transaction aborted PSW is defined as the contents of the current PSW, except that the address of the abort PSW operation instruction designates the TBEGINC instruction (in instead of the next sequential TBEGINC instruction).
[0138] When a transaction is aborted, the condition code in the transaction aborted PSW is replaced with a code that indicates the severity of the abort condition. Subsequently, if the operation was aborted due to causes that did not result in an interrupt, the PSW is loaded from the PSW abort transaction; if the operation was aborted due to causes that result in an interrupt, the abort PSW transaction is stored as the old interrupt PSW.
[0139] The PSW abort transaction is not changed during the execution of any inner BEGIN TRANSACTION statement.
[0140] Settlement Transaction Depth (TND)
[0141] Transaction nesting depth is, for example, an unsigned 16-bit value that is incremented each time a transaction BEGIN instruction completes with condition code 0 and decremented each time an END TRANSACTION instruction completes. The transaction nesting depth is reset when a transaction is aborted or by CPU reset.
[0142] In one embodiment, a maximum of TND 15 is implemented.
[0143] In one embodiment, when the CPU is in transactional constrained execution mode, the nesting depth is one transaction. Also, although the maximum TND can be represented as a 4-bit value, the TND is defined to be a 16-bit value to facilitate its inspection in the transaction diagnostic block.
[0144] Transaction diagnostic block (TDB)
[0145] When a transaction is aborted, various status information can be saved in a diagnostic transaction block (TDB), as follows:
[0146] 1. TBEGIN-specified TDB: For an unconstrained transaction, when the Bi field of the outermost TBEGIN instruction is non-zero, the first address operand of the instruction designates the TBEGIN-specified TDB. This is a specified local application program that can be examined by the application's interrupt handler.
[0147] 2. Program-Interrupt (PI) TDB: If an unconstrained transaction is aborted due to an unfiltered program exception condition, or if a restricted transaction is aborted due to any program exception condition (i.e., any condition that results in an interrupt of the program being acknowledged), the PI-TDB is stored in locations in the prefix area. This option is available for the operating system to inspect and log out of any diagnostic reports it may provide.
[0148] 3. TDB Interception: If the transaction is aborted due to any program exception condition that results in the interception (that is, the condition causes the interpretive execution to end and control to return to the host program), the TDB is stored in a location specified in the state block description for the guest operating system.
[0149] The TBEGIN-specified TDB is only stored, in one embodiment, when the address is valid TDB (ie, when the Bi field of the outermost TBEGIN instruction is non-zero).
[0150] For abort due to unfiltered program exception conditions, only one of either PI-TDB or Trap TDB will be stored. So there cannot be zero, one, two or TDBs stored to abort.
[0151] Further details regarding an example of each of the TDBs are described below:
[0152] specified by TBEGIN TDB: The 256-byte location specified by a valid transaction diagnostic block address. When the transaction diagnostic block address is valid, the specified TDB-TBEGIN is stored in an abort transaction. The TDB-specified TBEGIN is subject to all storage protection mechanisms that are in effect at the execution of the outermost operation start statement. A storage change PER (Event Recording Program) event for any part of the TBEGIN-specified TDB is detected during the execution of the outermost TBEGIN, not during the transaction abort processing.
[0153] One of the purposes of PER is to help debug programs. It allows the program to be alerted to the following types of events, as examples:
[0154] • Execution of a successful branch instruction. The option is provided of having an event occur only when the bypass destination location is within the designated storage area.
[0155] • Fetching an instruction from the designated storage area.
[0156] • modification of the contents of the designated storage area. The option is provided of having an event occur only when the storage area is within designated address spaces.
[0157] • Execution of a store using the real address instruction.
[0158] • Execution of the TRANSACTION END instruction.
[0159] The program may selectively specify that one or more of the above event types be acknowledged, except that the STORE event using the actual address can only be specified together with the store change event. Information regarding a PER event is provided to the program via a program interrupt, with the cause of the interrupt being identified in the interrupt code.
[0160] When transaction diagnostic block address is not valid, a TDB-specified TBEGIN is not stored.
[0161] Program-Interrupt TDB: Actual locations 6,144-6,399 (1800-18FF hex). Program interrupt TDB is stored when a transaction is aborted due to program interrupt. When a transaction is aborted due to other causes, the contents of the TDB interrupt program are unpredictable.
[0162] The interruption of the TDB program is not subject to any protection mechanism. PER storage change events are not detected by the program interrupt TDB when it is stored during a program interrupt.
[0163] TDB Intercept: The actual host location of 256 bytes specified by locations 488-495 of the state description. The TDB trap is stored when an aborted transaction results in a guest program interrupt trap (ie, trap code 8). When a transaction is aborted due to other causes, the contents of the TDB intercept are unpredictable. TDB interception is not subject to any protection mechanism.
[0164] As depicted in Figure 9, the fields of a diagnostic transaction block 900 are as follows, in one embodiment:
[0165] Format 902: Byte 0 contains an indication of validity and format, as follows:
[0166] Value Meaning 0 The remaining TDB fields are unpredictable. 1 1 A Format- TDB, the remaining fields of which are described below. 2-255 Reserved
[0167] A TDB in which the format field is zero is referred to as a null TDB.
[0168] Flags 904: Byte 1 contains several indications, as follows:
[0169] Conflict Token Validity (CTV): When a transaction is aborted due to a fetch or store conflict (i.e. abort codes 9 or 10 respectively), bit 0 of byte 1 is the indication of conflict token validity . When the indication is a CTV, the 910-byte conflict token in 16-23 of the TDB contains the logical address where the conflict was detected. When the CTV indication is zero, bytes 16-23 of TDB are unpredictable.
[0170] When a transaction is aborted due to any reason other than a fetch or store conflict, bit 0 of byte 1 is stored as zero.
[0171] Restricted-Transaction Indication (CTI): When the CPU is in restricted transactional execution mode, bit 1 of 1 byte is set to one. When the CPU is in nonconstrained transactional execution mode, bit 1 of 1 byte is set to zero.
[0172] Reserved: 1-byte bits 2-7 are reserved, and stored as zeros.
[0173] Transaction Nesting Depth (TND) 906: 6-7 Bytes contain the transaction nesting depth when the operation was aborted.
[0174] Transaction Abort Code (TAC) 908: 8-15 Bytes contain a 64-bit unsigned transaction abort code. Each code point indicates a reason for a transaction being aborted.
[0175] It is model dependent on whether the transaction abort code is stored in the TDB interrupt program when a transaction is aborted due to conditions other than a program interrupt.
[0176] Token Conflict 910: For transactions that are aborted due to conflict fetch or storage (i.e., abort codes 9 and 10, respectively), bytes 16-23 contain the logical address of the storage location at which the token was detected. conflict. The conflict token is significant when the CTV bit, bit 0 of byte 1, is one of them.
[0177] When the CTV bit is zero, bytes 16-23 are unpredictable.
[0178] Because of speculative execution by the CPU, the conflict token may designate a storage location that would not necessarily be accessed by the transaction's conceptual execution sequence.
[0179] Aborted Instruction Transaction Address (ATIA) 912: 24-31 Bytes contain an instruction address that identifies the instruction that was executing when an abort was detected. When a transaction aborts due to aborting codes 2, 5, 6, 11, 13, or 256 or higher, or when a transaction aborts due to aborting codes 4 or 13 and the program exception condition is aborting, ATIA points directly to the instruction that was being executed. When a transaction is aborted due to abort codes 4 or 12, and the program exception condition is not aborting, the Atia points past the instruction that was being executed.
[0180] When a transaction is aborted due to abort codes 7-10, 14-16, or 255, ATIA does not necessarily indicate the exact instruction causing the abort, but may point to an instruction earlier or later within the transaction.
[0181] If a transaction is aborted due to an instruction that is the target of an execute-type instruction, ATIA identifies the execute-type instructions, either pointing to the instruction or passed, according to the interrupt code, as described above. ATIA does not indicate the target of the run-type instruction.
[0182] ATIA is subject to addressing mode when transaction is aborted. In 24-bit addressing mode, bits 0-40 of the field contain zeros. In 31-bit addressing mode, bits 0-32 of the field contain zeros.
[0183] It is dependent on whether the transaction aborted instruction address is stored in the TDB interrupt program when a transaction is aborted due to conditions other than a program interrupt model.
[0184] When a transaction is aborted due to abort code 4 or 12, and the program exception condition does not abort, the ATIA does not point to the instruction causing the abort. By subtracting the number of halfwords indicated by the ATIA interrupt length code (ILC), the instruction causing the abort can be identified by conditions that suppress or terminate, or by non-PER events that are completing. When a transaction is aborted due to a per event, and no other program exception conditions are present, ATIA is unpredictable.
[0185] When the transaction diagnostic block address is valid, the ILC can be examined in the program interrupt ID (PUD) in bytes 36-39 of the specified TDB-TBEGIN. When filtering does not apply, the CLI can be probed to the DPU at location 140-143 in actual storage.
[0186] Access Exception ID (eaid) 914: For transactions that are aborted due to certain filtered program exception conditions, byte 32 of the specified TDB- TBEGIN contains the exception access ID. In an example of the z/Architecture architecture, the format of eaid, and the cases in which it is stored, are the same as described in the actual location 160, when the exception condition results in an interrupt, as described in the above incorporated by reference principles of the Operation.
[0187] For transactions that abort for other reasons, including any exception conditions that result in a program interruption, byte 32 is unpredictable. Byte 32 is unpredictable in the program interrupt TDB.
[0188] This field is only stored in the TDB designated by the transactional diagnostic block address; otherwise, the field is reserved. The eaid is stored only for controlled access list or DAT protection, type ASCE, page translation, region first translation, region second translation, region third translation, and program exception conditions segment translation.
[0189] Data Exception Code (DXC) 916: For transactions that are aborted due to program exception conditions filtered data exception, byte 33 of the specified TBEGIN TDB contains the data exception code. In an example of the z/Architecture architecture, the format of the DXC, and the cases in which it is stored, are the same as those described in the actual location 147, when the exception condition results in an interrupt, as described in the above incorporated by reference principles of the Operation. In one example, location 147 includes the DXC.
[0190] For transactions that abort for other reasons, including any exception conditions that result in a program interruption, byte 33 is unpredictable. Byte 33 is unpredictable in the program interrupt TDB.
[0191] This field is only stored in the TDB designated by the transactional diagnostic block address; otherwise, the field is reserved. DXC is only stored for program data exception conditions.
[0192] Program Interrupt ID (PUD) 918: For transactions that are aborted due to filtered program exception conditions, bytes 36-39 of the specified TDB-TBEGIN contain the program interrupt ID. In an example of the z/Architecture architecture, the PUD format is the same as that described in real locations 140-143 when the condition results in an interrupt (as described in the previously incorporated by reference Working Principles), except that the instruction length code in bits 13-14 of the PUD is respective to the instruction in which the exception condition was caught.
[0193] For transactions that abort for other reasons, including exception conditions that result in a program interruption, bytes 36-39 are unpredictable. Bytes 36-39 are unpredictable in the program interrupt TDB.
[0194] This field is only stored in the TDB designated by the transactional diagnostic block address; otherwise, the field is reserved. The program interrupt ID is only stored for program exception conditions.
[0195] Translation Exception ID (TEID) 920: For transactions that are aborted due to any of the following filtered program exception conditions, bytes 4047 of the TBEGIN-specified TDB contain the translation exception ID.
[0196] Controlled DAT protection access list or
[0197] ASCE type
[0198] Translation Page
[0199] Region-first translation
[0200] Second translation region
[0201] Region third translation
[0202] Segment translation exception
[0203] In an example of the z/Architecture architecture, the format of the TEID is the same as that described in real locations 168-175 when the condition results in an interrupt, as described in the previously incorporated by reference Operating Principles.
[0204] For transactions that abort for other reasons, including exception conditions that result in a program interruption, bytes 40-47 are unpredictable. Bytes 40-47 are unpredictable in the program interrupt TDB.
[0205] This field is only stored in the TDB designated by the transactional diagnostic block address; otherwise, the field is reserved.
[0206] Breaking Event Address 922: For transactions that are aborted due to filtered program exception conditions, bytes 48-55 of the specified TDB-TBEGIN contain the address of the breaking event. In an example of the z/Architecture architecture, the format of the burst event address is the same as that described in real locations 272-279 when the condition results in an outage, as described in the previously incorporated by reference Operating Principles.
[0207] For transactions that abort for other reasons, including exception conditions that result in a program interruption, bytes 48-55 are unpredictable. Bytes 48-55 are unpredictable in the program interrupt TDB.
[0208] This field is only stored in the TDB designated by the transactional diagnostic block address; otherwise, the field is reserved.
[0209] More details regarding burst events are described below.
[0210] In one embodiment of the z/Architecture architecture, when the PER-3 facility is installed, it provides the program with the address of the last instructions to cause a disruption in the sequential execution of the CPU. Breaking event address recording can be used as a debug helper for wild branch detection. This facility provides, for example, a 64-bit register in the CPU, called a burst event address register. Each time an instruction other than transaction abort causes a break in the execution of the sequential instruction (that is, the address of the instruction in the PSW is replaced, rather than incremented by the length of the instruction), the address at which the instruction is placed in the break event log address. Whenever a program interrupt occurs, or no PER is indicated, the current contents of the rupture event address register are placed in actual storage locations 272-279.
[0211] If the instruction causing the break event is the target of an execution type of instructions (EXECUTE or RELATIVE LONG execute), then the instruction address used to fetch the execute type instruction is placed in the address register break event.
[0212] In an embodiment of the z/Architecture architecture, a break event is considered to occur whenever one of the following instructions causes branching: BRANCH AND LINK (BAL, BALR); BRANCH AND SAVE (BAS, basr); BRANCH AND SAVE AND SET MODE (BASSM); BRANCH AND SET MODE (BSM); BRANCH AND STACK (Bakr); BRANCH IN CONDITION (BC, BCR); BRANCH NO COUNT (BCT, BCTR, BCTG, BCTGR); BRANCH IN HIGH INDEX (BXH, BXHG); BRANCH AT LOW INDEX or equal (BXLE, BXLEG); BRANCH IN RELATIONSHIP ON CONDITION (BRC); BRANCH IN RELATION TO THE LONG CONDITION (BrCl); BRANCH IN RELATIONSHIP COUNT (BRCT, BRCTG); Relative BRANCH in the bullish index (BRXH, BRXHG); BRANCH IN RELATIONSHIP low OR EQUAL (BRXLE, BRXLG); Compare and BRANCH (CRB, CGRB); Compare and relative RAMO (CRJ, CGRJ); COMPARE IMMEDIATE and branch (CIB, CGIB); COMPARE IMMEDIATE and relative branch (CIJ, CGIJ); COMPARE logical and BRANCH (CLRB, CLGRB); COMPARE logical and relative BRANCH (CLRJ, CLGRJ); COMPARE IMMEDIATE LOGIC and branch (CLIB, CLGIB); and COMPARE LOGIC immediate relative and branch (CLIJ, CLGU).
[0213] A breakout event is also considered to occur whenever one of the following completes: BRANCH AND AUTHORITY SET (BSA); BRANCH IN THE SUBSPACE GROUP (BSG); RELATED BRANCH AND SAVE (BRAS); RELATIVE BRANCH AND SAVE LONG (Brazil); PSW LOAD (LPSW); LOAD PSW EXTENDED (LPSWE); Program call (PC); Return Program (PR); TRANSFER PROGRAM (PT); PROGRAM TRANSFER WITH INSTANCE (PTI); RESUME PROGRAM (RP); and TRAP (TRAP2, TRAP4).
[0214] A break event is not considered to occur as a result of a transaction being aborted (implicitly or as a result of the transaction abort instruction).
[0215] Model Dependent Diagnostic Information 924: 112-127 Bytes contain model dependent diagnostic information.
[0216] For all codes except 12 (filtered program interrupt) abort, model dependent diagnostic information is saved in each TDB that is stored.
[0217] In one embodiment, the dependent diagnostic information model includes the following:
[0218] • Bytes 112-1 19 contain a 64-bit vector called the Transactional Execution Branch Indications (TXBI). Each of the first 63 bits of the vector indicates the results of executing a branch instruction while the CPU was in transaction execution mode, as follows:
[0219] Value Meaning
[0220] The instruction completed without branching.
[0221] 1 The instruction completed with branch.
[0222] Bit 0 represents the result of the first such branch instruction, bit 1 represents the result of the second such instruction, and so on.
[0223] If fewer than 63 branch instructions were executed while the CPU was in transactional execution mode, the rightmost bits that do not correspond to branch instructions are set to include zeros (63 bits). When more than 63 branch instructions have been executed, bit 63 of the TXBI is set to one.
[0224] Bits in the TXBI are set by instructions that are capable of triggering a burst event as listed above, except for the following:
[0225] - Any restricted instruction does not cause a bit to be defined in the TXBI.
[0226] - For instructions from, for example, naz/Architecture, when the field of the M1 BRANCH IN CONDITION, RELATIVE BRANCH IN CONDITION, or BRANCH IN RELATION TO CONDITION OF LONG instruction is equal to zero, or when the field R2 of the following instructions is zero, it is model dependent if the execution of the instruction causes a bit to be defined in the TXBI.
[0227] BRANCH AND LINK (BALR); BRANCH AND SAVE (basr); BRANCH AND SAVE AND SET MODE (BASSM); BRANCH AND SET MODE (BSM); BRANCH IN CONDITION (BCR); and BRANCH NO COUNT (BCTR, BCTGR)
[0228] To abort conditions that were caused by a host access exception, bit position 0 of byte 127 is set to one. For all other abort conditions, bit 0 of byte position 127 is set to zero.
[0229] To abort conditions that were detected by the load/store unit (LSU), the rightmost five pieces of byte 127 contain the indication of the cause. To abort conditions that were not detected by the LSU, byte 127 is reserved.
[0230] General Registers 930: Bytes 128-255 contain the contents of general registers 0-15 at the time the operation was aborted. Registers are stored in ascending order, starting with general register 0 at bytes 128-135, general register 1 at bytes 136-143, and so on.
[0231] Reserved: All other fields are reserved. Unless otherwise noted, the contents of reserved fields are unpredictable.
[0232] As noted by other CPUs and the I/O subsystem, TDB storage(s) during a transaction abort is a multiple access reference that occurs after all non-transactional stores.
[0233] An operation may be aborted due to causes that are outside the scope of the immediate configuration in which it executes. For example, transient events recognized by a hypervisor (such as LPAR or z/VM) can cause a transaction to abort.
[0234] The information provided in the transaction diagnostic block is intended for diagnostic purposes and is substantially correct. However, because an abort may have been caused by an event outside the scope of the immediate configuration, information such as the abort code or program interruption identification may not accurately reflect conditions within the configuration, and therefore should not be used. to determine the program action.
[0235] In addition to the diagnostic information saved in the TDB, when a transaction is aborted due to any exception condition program data exception and both AFP register-control, bit 45 of register 0 control, and the effective allow floating control operation point (F) are one, the data exception code (DXC) is placed in byte 2 of the floating point control register (FPCR), regardless of filtering applies to the program exception condition. When a transaction is aborted, and one or both of the AFP control register or effective floating-point operation control allow are zero, the DXC is not placed in the FPCR.
[0236] In one embodiment, as indicated herein, when the transaction execution facility is installed, the following general instructions are provided.
[0237] EXTRACT TRANSACTION NESTING DEPTH
[0238] NONTRANSACTIONAL STORE
[0239] TRANSACTION ABORT
[0240] TRANSACTION BEGIN
[0241] TRANSACTION END
[0242] When the CPU is in transactional execution mode, attempted execution of certain instructions is restricted and causes the operation to be aborted.
[0243] When issued in constrained transactional execution mode, attempted execution of constrained instructions may also result in an interruption of program operation constraint, or may result in process execution as if the transaction was not constrained.
[0244] In a z/Architecture example, restricted instructions include, for example, the following unprivileged instructions: COMPARE AND SWAP AND STORE; MODIFY RUNTIME INSTRUMENTATION CONTROLS; PERFORM LOCKED OPERATION; PREFETCH DATA (RELATIVE LONG), when the code in the M1 field is 6 or 7; STORE CHARACTERS UNDER MASK HIGH, when the M3 field is zero and the code in the R1 field is 6 or 7; STORE FACILITY LIST EXTENDED; STORE RUNTIME INSTRUMENTATION CONTROLS; CALL SUPERVISOR; and TEST RUNTIME INSTRUMENTATION CONTROLS.
[0245] In the list above, COMPARE AND SWAP AND STORE and PERFORM LOCKED OPERATION are complex instructions that can be implemented more efficiently using basic instructions in TX mode. The cases of PREFETCH DATA and PREFETCH DATA RELATIVE LONG are restricted as codes 6 and 7 to flush a cache line, potentially requiring data commitment before a transaction is completed. SUPERVISOR CALL is restricted in that it causes an interrupt (which causes a transaction to abort).
[0246] Under the conditions listed below, the following instructions are restricted:
[0247] BRANCH AND LINK (BALR), BRANCH AND SAVE (BASR), and BRANCH AND SAVE AND SET MODE, when the R2 instruction field is non-zero and branch tracking is enabled.
[0248] BRANCH AND SAVE AND SET MODE and BRANCH AND SET MODE, when the R2 field is non-zero and tracking mode is enabled; SET ADRESSING MODE, when tracking mode is on.
[0249] MONITOR CALL, when a monitor event condition is recognized.
[0250] The above list includes instructions that can form trace entries. If these instructions were allowed to execute trace entries transactionally and formed, and the transaction subsequently aborted, the trace table pointer in control register 12 would be advanced, but the stores for the trace table would be discarded. This would leave an inconsistent gap in the trace table. Thus, statements are restricted in cases where they form trace entries.
[0251] When the CPU is in transactional execution mode, it is dependent on whether the following instructions are model constrained: CIPHER MESSAGE; CIPHER MESSAGE WITH CFB;CIPHER MESSAGE WITH CHAINING; CIPHER MESSAGE WITH COUNTER; CIPHER MESSAGE WITH OFB; COMPRESSION CALL; COMPUTE INTERMEDIATE MESSAGE DIGEST; COMPUTE LAST MESSAGE DIGEST; COMPUTE MESSAGE AUTHENTICATION CODE; CONVERT UNICODE-16 TO UNICODE-32; CONVERT UNICODE-16 TO UNICODE-8; CONVERTUNICODE-32 TO UNICODE-16; CONVERT UNICODE-32 TO UNICODE-8; CONVERT UNICODE-8 TO UNICODE-16; CONVERT UNICODE-8 TO UNICODE-32; PERFORM CRYPTOGRAPHIC COMPUTATION; RUNTIME INSTRUMENTATION OFF; and RUNTIME INSTRUMENTATION ON..
[0252] Each of the above instructions is either currently implemented by the hardware coprocessor, or was on machines in the past and is therefore considered restricted.
[0253] When an effective control (A) of allowing AR modification is zero, the following instructions are restricted: COPY ACCESS; LOAD ACCESS MULTIPLE; LOAD ADDRESS EXTENDED; and SET ACCESS.
[0254] Each of the instructions above causes the contents of an access record to be modified. If the A control in the BEGIN TRANSACTION statement is zero, then the program has explicitly indicated that access register modification should not be allowed.
[0255] When the allow effective operation of floating (F) control point is zero, floating point instructions are restricted.
[0256] Under certain circumstances, the following instructions may be restricted: EXTRACT CPU TIME; EXTRACT PSW; STORE CLOCK; STORE CLOCK EXTENDED; and STORE CLOCK FAST.
[0257] Each of the above instructions is subject to an interception control in the interpretive execution state description. If the hypervisor has not set trap control for these statements, then their execution may be delayed due to the hypervisor implementation; Thus, they are considered restricted if an intercept occurs.
[0258] When an unconstrained transaction is aborted because of an attempt to execute a constrained instruction, the transaction abort code in the diagnostic block transaction is set to 1 1 (constrained instruction), and the condition code is set to 3, with the following exceptions: when an unconstrained transaction is aborted due to the attempt to execute an instruction that would otherwise result in a privileged operation exception, it is unpredictable if the interrupt code is set to 1 1 (restricted instruction) or 4 ( unfiltered program interruption resulting from recognition of program interruption privileged operation). When an unconstrained transaction is aborted due to an attempt to execute PREFETCH DATA (RELATIVE LONG) when the code in the M1 field is 6 or 7 or STORE CHARACTERS UNDER MASK HIGH when the M3 field is zero and the code in the R1 field is 6 or 7, it is unpredictable if the interrupt code is set to 1 1 (restricted instruction) or 16 (other cache). When an unconstrained transaction is aborted due to attempted call monitor execution, and both the monitor event condition and a specification exception condition are present it is unpredictable if the interrupt code is set to 11 or 4, or, if the program interrupt is filtered out, 12.
[0259] Additional instructions may be restricted in a restricted transaction. Although these instructions are not currently defined to be constrained in an unconstrained transaction, they may be constrained, under certain circumstances, in an unconstrained transaction on future processors.
[0260] Certain restricted instructions may be allowed in transactional execution mode on future processors. Therefore, the program should not rely on the transaction being aborted due to the attempt to execute a constrained instruction. The TRANSACTION ABORT statement must be used to reliably cause a transaction to be aborted.
[0261] In an unconstrained transaction, the program must provide an alternative non-transactional code path to accommodate a transaction that aborts due to a constrained instruction.
[0262] In operation, when the transaction nesting depth is zero, the execution of the BEGIN TRANSACTION (TBEGIN) instruction, resulting in zero condition code causes the CPU to enter unconstrained transactional execution mode. When the transaction nesting depth is zero, execution of the constrained TRANSACTION BEGIN (TBEGINC) instruction, resulting in zero condition code causes the CPU to enter constrained transactional execution mode.
[0263] Unless expressly stated otherwise, all rules that apply to non-transactional execution also apply to transactional execution. These are additional processing features while the CPU is in transactional execution mode.
[0264] When the CPU is in unrestricted transactional execution mode, execution of the TRANSACTION BEGIN instruction resulting in zero condition code causes the CPU to remain in unrestricted transactional execution mode.
[0265] As noted by the CPU, fetches and stores done in transaction execution mode are no different than those done while not in transactional execution mode. As noted by other CPUs and the I/O subsystem, all storage operand accesses made while a CPU is in transactional execution mode appear to be a single concurrent access block. That is, accesses to all bytes within a halfword, word, doubleword, or quadword are specified to appear to be of concurrent component as observed by other processors and (eg, channel programs) I/O. The halfword, word, doubleword, or quadword is referred to in this section as a block. When a fetch-type reference is specified to appear to be concurrent within a block, no store access to the block by another CPU or program I/O is allowed during the time the bytes contained in the block are being fetched. When a storage reference of type is specified to appear to be concurrent within a block, no access to the block, either fetch or store, is allowed by another CPU or I/O program during the time that the bytes within the block are being stored.
[0266] Storage accesses for instruction and lookup DAT and ART (Access Register Table) table follow non-transactional rules.
[0267] The CPU exits transactional execution mode normally via a TRANSACTION END instruction which causes the transaction nesting depth to transition to zero, in which case, the transaction completes.
[0268] When the CPU leaves transactional execution mode upon completion of a TRANSACTION END instruction, all stores done while in transactional execution mode are committed; that is, the stores appear to occur as a single concurrent operation block as observed by other CPUs and the I/O subsystem.
[0269] A transaction may be aborted implicitly for a variety of causes, or it may be explicitly aborted by the transaction abort instruction. Example possible causes of an abort operation, the corresponding interrupt code, and the condition code that is placed in the abort PSW transaction are described below.
[0270] External interrupt: Transaction abort code is set to 2, and condition code in transaction abort PSW is set to 2. Transaction abort PSW is stored as old external PSW as part of external interrupt processing.
[0271] Program Interrupt (unfiltered): The program exception condition that results in an interrupt (that is, an unfiltered condition) causes the transaction to abort with code 4. The condition code in the PSW abort transaction is defined specific to the program interrupt code. The PSW abort transaction is stored as the old PSW program as part of the program's interrupt processing.
[0272] An instruction that would otherwise result in a transaction being aborted due to an operation exception may produce alternative results: for an unconstrained transaction, the transaction can abort with code instead of aborting 1 1 (constrained instruction) ; for a constrained transaction, a transaction constraint program interrupt may be recognized instead of the operation exception.
[0273] When a PER (Program Event Recording) event is acknowledged in conjunction with any other unfiltered program exception condition, the condition code is set to 3.
[0274] Machine Check Abort: The transaction abort code is set to 5, and the condition code in the PSW abort transaction is set to 2. The PSW abort transaction is stored as the PSW stale machine check as a check part machine interrupt processing.
[0275] I/O Interrupt: The abort transaction code is set to 6, and the condition code in the transaction aborted PSW is set to 2. The abort PSW operation is stored as the old I/O PSW as a part of I /The interrupt processing.
[0276] Fetch overflow: A fetch overflow condition is detected when the transaction attempts to fetch from more locations than the CPU supports. The transaction abort code is set to 7, and the condition code is set to 2 or 3.
[0277] Storage Overflow: A store overflow condition is detected when the transaction attempts to store to more locations than the CPU supports. The transaction abort code is set to 8, and the condition code is set to 2 or 3.
[0278] Allowing the condition code to be 2 or 3 in response to a fetch or store abort overflow allows the CPU to indicate potentially repeatable situations (e.g., condition code 2 indicates re-execution of the operation may be productive, while condition code 3 does not recommend re-execution).
[0279] Fetch Conflict: A fetch conflict condition is detected when another CPU or I/O subsystem attempts to store to a location that was transactionally fetched by this processor. The transaction abort code is set to 9, and the condition code is set to 2.
[0280] Store conflict: The store conflict condition is detected when another CPU or IO subsystem tries to access a location that was stored during transactional execution by this processor. The transaction abort code is set to 10, and the condition code is set to 2.
[0281] Restricted Instruction: When the CPU is in transactional execution mode, an attempt to execute a constrained instruction causes the operation to be aborted. The transaction abort code is set to 11, and the condition code is set to 3.
[0282] When the CPU is in transactional constrained execution mode, it is unpredictable whether the attempt to execute a constrained-access instruction results in a transaction constraint program interrupt or an abort due to a constrained instruction. The transaction is still aborted, but the interrupt code could indicate any cause.
[0283] Program Exception Condition (filtered): A program exception condition that does not result in an interrupt (ie, a filtered condition) causes the transaction to abort with a transaction abort code of 12. The condition code is set to 3.
[0284] Settlement Depth Exceeded: The nesting depth exceeded condition is detected when the transaction nesting depth is at the maximum value allowed for the configuration, and a transaction BEGIN instruction is executed. The transaction is aborted with a transaction abort code of 13 and the condition code is set to 3.
[0285] Cache Fetch Related Condition: A condition related to transaction fetched storage locations is detected by the CPU cache circuit. The transaction is aborted with a transaction abort code of 14, and the condition code is set to 2 or 3.
[0286] Condition related to cache storage: A condition related to storage locations stored by the transaction is detected by the CPU cache circuit. The transaction is aborted with a transaction abort code of 15, and the condition code is set to 2 or 3.
[0287] Other Cache Condition: A cache another condition is detected by the CPU's cache circuitry. The transaction is aborted with a transaction abort code of 16, and the condition code is set to 2 or 3.
[0288] During transactional execution, if the CPU accesses instructions or storage operands using different logical addresses that are mapped to the same absolute address, it is model dependent if the transaction is aborted. If the transaction is aborted due to accesses using different logical addresses mapped to the same absolute address, abort code 14, 15, or 16 is set, depending on the condition.
[0289] Miscellaneous State: Varied condition is any other condition recognized by the CPU that causes the transaction to abort. The transaction abort code is 255 and the condition code is set to 2 or 3.
[0290] When multiple configurations are running on the same machine (eg logical partitions or virtual machines), an operation may be aborted due to an external machine control or I/O interrupt that occurred in a different configuration.
[0291] Although examples are provided above, other causes of a transaction abort with corresponding abort codes and condition codes may be provided. For example, one cause might be a Restart Interrupt, where the transaction abort code is set to 1, and the condition code in the transaction aborted PSW is set to 2. The transaction abort PSW is stored as the old restart PSW as a part of restart processing. As an additional example, a cause could be a condition called supervisor, where the interrupt code is set to 3, and the condition code in the transaction aborted PSW is set to 3. Other or different examples are also possible.
[0292] Notes:
[0293] 1. Varied condition can result from any of the following:
[0294] Instructions, such as, in z/Architecture, COMPARE AND REPLACE DAT TABLE ENTRY, COMPARE AND SWAP AND PURGE, INVALIDATE DAT TABLE ENTRY, INVALIDATE PAGE TABLE ENTRY, PERFORM FRAME MANAGEMENT FUNCTION in which the control NQ is zero and the control SK is one, SET STORAGE KEY EXTENDED where the control NQ is zero, performed by another processor in the configuration; the condition code is set to 2.
[0295] An operator function such as reset, restart or stop, or the equivalent order SIGNAL PROCESSOR is executed on the CPU.
[0296] Any other condition not listed above; the condition code is set to 2 or 3.
[0297] 2. The location where to fetch and store conflicts are detected can be anywhere within the same cache line.
[0298] 3. Under certain conditions, the CPU may not be able to distinguish between similar abort conditions. For example, an overflow fetch or store might be indistinguishable from a respective fetch or store conflict.
[0299] 4. Speculative execution of multiple instruction paths by the CPU may result in a transaction being aborted due to deadlock or overflow conditions, even if such conditions do not occur in the conceptual sequence. While in constrained transactional execution mode, the CPU may temporarily inhibit speculative execution, allow the operation to attempt to complete without detecting such conflicts, or overflow speculatively.
[0300] Execution of a transaction abort instruction causes the transaction to abort. The transaction abort code is defined from the second address of the operand. The condition code is set to 2 or 3, depending on whether bits 63 of the second address of the operand is zero or one, respectively.
[0301] Figure 10 summarizes example abort codes stored in a transaction diagnostic block, and the corresponding condition code (CC). The description in figure 10 illustrates a particular implementation. Other implementations and encodings of values are possible.
[0302] In one embodiment as mentioned above, the transactional facility provides for both constrained and unconstrained transactions, as well as processing associated therewith. Initially, restricted operations are discussed and then unrestricted transactions.
[0303] Restricted operation runs in transactional mode without a fall-back path. It is a useful processing mode for compact functions. In the absence of repeated interrupts or conflicts with other CPUs or the I/O subsystem (that is, caused by conditions that will not allow the transaction to complete successfully), a constrained operation will end completely; Thus, an interrupt handler is not needed and is not specified. For example, in the absence of violation of a condition that cannot be handled (eg division by 0); a condition that does not allow the operation to complete (eg, an interrupt timer that does not allow an instruction to execute; a hot I/O, etc.); or a constraint violation or constraint associated with a constrained transaction, the operation will end entirely.
[0304] Constrained operation is initiated by a constrained TRANSACTION BEGIN (TBEGINC) instruction when the transaction nesting depth is initially zero. A restricted transaction is subject to the following restrictions, in one embodiment.
[0305] 1. The transaction executes no more than 32 instructions, not including BEGIN TRANSACTION constrained (TBEGINC) and TRANSACTION END statements.
[0306] 2. All instructions in the transaction must be within 256 contiguous bytes of storage, including the strict TRANSACTION BEGIN (TBEGINC) instructions and any TRANSACTION END.
[0307] 3. In addition to the restricted access instructions, the following restrictions apply to a restricted transaction.
[0308] a. Instructions are limited to instructions referred to as general, including, for example, add, subtract, multiply, divide, transfer, rotate, etc.
[0309] b. Branch instructions are limited to the following (the instructions listed are from z/Architecture in an example):
[0310] BRANCH RELATIVE ON CONDITION where M1 is non-zero and the RI2 field contains a positive value.
[0311] BRANCH RELATIVE ON CONDITION LONG where the M1 field is non-zero, and the RI2 field contains a positive value that does not cause address involvement.
[0312] COMPARE AND BRANCH RELATIVE, COMPARE IMMEDIATE AND BRANCH RELATIVE, COMPARE LOGICAL AND BRANCH RELATIVE, and COMPARE LOGICAL IMMEDIATE AND BRANCH RELATIVE where the M3 field is non-zero and the RI4 field contains a positive value. (That is, only forward branches with non-zero branch masks.)
[0313] c. Except for TRANSACTION END and instructions that cause a specified operand serialization, instructions that cause a serialization function are restricted.
[0314] d. Store and Store Operations (SS constitutes), and store-and-store operations with an extended operation code (SSE-) instructions are restricted.
[0315] e.g. All of the following general statements (which are from z/Architecture, in this example) are restricted: CHECKSUM; CIPHER MESSAGE; CIPHER MESSAGE WITH CFB; CIPHER MESSAGE WITH CHAINING; CIPHER MESSAGE WITH COUNTER; CIPHER MESSAGE WITH OFB; COMPARE AND FORM CODEWORD; COMPARE LOGICAL LONG; COMPARE LOGICAL LONG EXTENDED; COMPARE LOGICAL LONG UNICODE; COMPARE LOGICAL STRING; COMPARE UNTIL SUBSTRING EQUAL; COMPRESSION CALL; COMPUTE INTERMEDIATE MESSAGE DIGEST; COMPUTE LAST MESSAGE DIGEST; COMPUTE MESSAGE AUTHENTICATION CODE; CONVERT TO BINARY; CONVERT TO DECIMAL; CONVERT UNICODE-16 TO UNICODE-32; CONVERT UNICODE-16 TO UNICODE-8; CONVERT UNICODE-32 TO UNICODE-16; CONVERT UNICODE-32 TO UNICODE-8; CONVERT UNICODE-8 TO UNICODE-16; CONVERT UNICODE-8 TO UNICODE-32; DIVIDE; DIVIDE LOGICAL; SINGLE SPLIT; RUN; RUN RELATIVE LONG; EXTRACT CACHE ATTRIBUTE; EXTRACT CPU TIME; EXTRACT PSW; EXTRACT TRANSACTION NESTING DEPTH; LOADAND ADD; LOAD AND ADD LOGICAL; LOAD AND AND; LOAD AND EXCLUSIVE OR; LOAD AND OR; LOAD PAIR DISJOINT; LOAD PAIR FROM QUAD WORD; CALL MONITOR; LONG MOVE; MOVE LONG EXTENDED; MOVE LONG UNICODE; MOVE STRING; NON-TRANSACTIONAL STORE; PERFORM CRYPTOGRAPHIC COMPUTATION; PREFETCH DATA; PREFETCH DATA RELATIVE LONG; RUNTIME INSTRUMENTATION EMIT; RUNTIME INSTRUMENTATION NEXT; RUNTIME INSTRUMENTATION OFF; RUNTIME INSTRUMENTATION ON; SEARCH STRING; SEARCH; STRING UNICODE; SET ADDRESSING MODE; STORE CHARACTERS UNDER MASK HIGH, when the M3 field is zero, and the code in the Ri field is 6 or 7; STORE CLOCK; STORE CLOCK EXTENDED; STORE CLOCK FAST; STORE FACILITY LIST EXTENDED; STORE PAIR TO QUADWORD; TEST ADDRESSING MODE; TRANSACTION ABORT; TRANSACTION BEGIN (both TBEGTN and TBEGINC); TRANSLATE AND TEST EXTENDED; TRANSLATE AND TEST REVERSE EXTENDED; TRANSLATE EXTENDED; TRANSLATE ONE TO ONE; TRANSLATE ONE TO TWO TRANSLATE TWO TO ONE; and TRANSLATE TWO TO TWO..
[0316] 4. Transaction store operands access no more than four octowords. Note: LOAD ON CONDITION and STORE ON CONDITION are considered as storage reference, regardless of condition code. An octoword is, for example, a group of 32 consecutive bytes on a 32-byte boundary.
[0317] 5. The transaction executing on this CPU, or stores by other CPUs or the I/O subsystem, does not access storage operands in any 4 Kbyte blocks that contain the 256 bytes of storage starting with the constrained TRANSACTION BEGIN (TBEGINC) instruction ).
[0318] 6. The operation does not access instructions or storage operands using different logical addresses that are mapped to the same absolute address.
[0319] 7. Operand references made by the transaction must be within a single doubleword, except that for LOAD ACCESS MULTIPLE, LOAD MULTIPLE, LOAD MULTIPLE HIGH, STORE ACCESS MULTIPLE, STORE MULTIPLE, and STORE MULTIPLE HIGH, the references are operands to be within a single octoword.
[0320] If a constrained transaction violates any of the constraints 1-7, listed above, then either (a) a program interrupt transaction constraint is acknowledged, or (b) execution proceeds as if the transaction were not constrained, except that further constraint violations can still result in a program interrupt constrained transaction. It is unpredictable what action will be taken, and the actions taken may vary depending on which constraint is violated.
[0321] In the absence of constraint violations, repeated interrupts, or conflicts with other CPUs or the I/O subsystem, a constrained operation will terminate altogether, as described above.
[0322] 1. The chance of successfully completing a constrained transaction improves if the transaction meets the following criteria:
[0323] A. The instructions issued are less than the maximum of 32.
[0324] b. Storage operand references are less than the 4 octo-word maximum.
[0325] c. The storage operand references are on the same cache line.
[0326] d. Storage operand references to the same locations occur in the same order across all transactions.
[0327] 2. A constrained operation is not necessarily guaranteed to complete successfully on its first run. However, if a constrained transaction that does not violate any of the listed constraints is aborted, the CPU employs circuitry to ensure that repeated execution of the transaction succeeds later.
[0328] 3. Within the term of a constrained operation, TRANSACTION BEGIN is a constrained statement, so a constrained operation cannot be nested.
[0329] 4. Violation of any of constraints 1-7 above by a constrained transaction may result in a program loop.
[0330] 5. The limitations of a constrained transaction are similar to those of a compare-and-swap loop. Due to possible interference from other CPUs and the I/O subsystem, there is no architectural guarantee that a COMPARE AND SWAP instruction will ever complete with condition code 0. A constrained operation may experience similar interference in the form of a fetch- or store- conflict. aborts or hot interruptions.
[0331] The CPU uses fairness algorithms to ensure that, in the absence of any constraint violations, a constrained transaction eventually completes.
[0332] 6. In order to determine the number of repeated iterations required to complete a constrained transaction, the program may hire an accountant in a general ledger that is not subject to the general register save mask. An example is shown below.LH1 15.0 ZeroLoop Repeat Counter TBEGINC 0(0),C' FE00' Preserve RGs 0-13 AHI 15.1 Increment counter... Transactional-execution code... constrained... TEND* R15 now contains the transactional retry count.
[0333] Note that both registers 14 and 15 are not restored in this example. Also note that on some models, the count in general register 15 may be low if the CPU detects the abort condition after the completion of the TBEGINC instruction, but before the completion of the AHI instruction.
[0334] As noted by the CPU, fetches and stores done in transactional execution mode are no different than those done while not in transaction execution mode.
[0335] In one embodiment, the user (ie creating a transaction) selects whether or not a transaction is being restricted. One embodiment of the logic associated with the processing of constrained transactions, and, in particular, the processing associated with a TBEGINC instruction, is described with reference to Figure 11. Execution of the TBEGINC instruction causes the CPU to enter execution mode transactional or remain in unrestricted execution mode. ACPU (i.e. the processor) executing TBEGINC executes the logic of figure 1 1.
[0336] With reference to Figure 11, based on the execution of a TBEGINC instruction, a serialization function is executed, step 1 100. A serialization function or operation includes completing all previous storage conceptually accesses (and, for oz /Architecture, as an example, and reference related to little change bit settings) by the CPU, as noted by other CPUs and by the I/O subsystem, before accessing the conceptually subsequent storage (and reference and change bit definitions) related bit) occurs. Serialization affects the sequence of all CPU accesses to storage and storage keys, except for those associated with the ART table entry and attractive DAT table entry.
[0337] As noted by a processor in transactional execution mode, serialization operates normally (as described above). As noted by other CPU and I/O subsystems, a serialization operation performed with a CPU that is in transactional execution mode occurs when the processor exits transaction execution mode, either as a result of an edge transaction instruction that slows down. the transaction nesting depth of zero (which terminates normally), or as a result of the operation being aborted.
[0338] After serialization is performed, a determination is made as to whether an exception is recognized, MESSAGE 1 102. If so, the exception is handled, STEP 1104. For example, a special exception operation is recognized and the operation is suppressed if transactional execution control, 8 control bits register 0, is 0. As other examples, a specification exception is recognized and operation is suppressed if the Bi field, bits 16-19 of the instruction, is different from zero; executing an exception is recognized and the operation is suppressed, if TBEGINC is the target of an instruction type execution; and an operation exception is recognized and the operation is suppressed, if the transaction execution facility is not installed in the configuration. If the CPU is already operating in constrained execution mode, then a constrained operation exception program exception is recognized and the operation is suppressed. Also, if the transaction nesting depth, when incremented by one, would exceed a model dependent on the maximum nesting transaction depth, the transaction is aborted with code abort 13. Other or different exceptions may be recognized and handled.
[0339] However, if there is no exception, then a determination is made as to whether the transaction nesting depth is zero, MESSAGE 1 106. If the transaction nesting depth is zero, then the address of the transaction block transaction diagnostic is considered invalid, STEP 1 108; the abort PSW transaction is defined from the contents of the current PSW, except that the address of the PSW abort operation instruction designates the TBEGINC instruction, rather than the next sequential instruction, STEP 1110; and the contents of the general record pairs as designated by the General Ledger economy mask are saved in a location dependent template that is not directly accessible by the program, STEP 1112. Also, the nesting depth is set to 1, STEP 1114. Additionally, the effective value of floating point operation enable (F) and program interrupt filtering controls (PIFC) are set to zero, STEP 1316. In addition, the effective value of change AR (A) enable control, bit 12 from the I2 field of the instruction, is determined, STEP 1118. For example, the effective control A is the logic AND of the A control in the TBEGINC instruction for the current level and for any outer TBEGIN instructions.
[0340] Going back to INQUIRITY 1106, if the transaction nesting depth is greater than zero, then the nesting depth is incremented by 1, STEP 1120. Also, the effective value of the floating point operation allow (F) is set to zero, and the effective value of the program interrupt filtering control (PIFC) remains unchanged, STEP 1122. Processing then continues with STEP 1118. In one embodiment, a successful initiation of the transaction results in the code condition 0. This completes an implementation of the logic associated with executing a TBEGINC instruction.
[0341] In one embodiment, the exception to the check provided above may variably occur. A particular order for exception checking is as follows:
[0342] Exceptions with the same priority as the priority of program interrupt conditions for the general case.
[0343] Specification exception due to Bi field containing a non-zero value.
[0344] Abort due to deeper nesting transaction.
[0345] Condition code 0, due to normal completion.
[0346] In addition, the following applies in one or more embodiments:
[0347] 1. Records designated to be saved by the general record save mask are only restored if the transaction is aborted, not when the transaction ends normally via TRANSACTION END. Only the GRSM-assigned registers of the outermost TRANSACTION BEGIN statement are restored on abort.
[0348] Field I2 must designate all record pairs that provide input values that are changed by a constrained transaction. Thus, if the transaction is aborted, the input registry values will be restored to their original contents when the constrained transaction is re-executed.
[0349] 2. In most models, improved performance can be realized, both in TRANSACTION BEGIN and when the transaction is aborted, by specifying the minimum number of records needed to be saved and restored in the general register save mask.
[0350] 3. The following illustrates the results of the transaction BEGIN instruction (both TBEGIN and TBEGINC) based on the current transaction nesting depth (TND) and, when a is non-zero TND, if the processor is in execution mode unconstrained or constrained transactional: TND instruction = 0TBEGIN Enter unconstrained execution transactional modeTBEGINC Enter constrained execution transactional mode TND instruction> 0TBEGIN NTX mode Mode CTXContinue in unconstrained transaction execution modetransaction constraint exceptionTBEGINC Continue in execution mode non-restricted transaction exception restricted transactional execution exception mode Explanation:CTX CPU is in transactional-NTX constrained execution mode CPU is in transactional-nonconstrained execution modeTND Transaction nesting depth at the beginning of the instruction.
[0351] As described herein, in one aspect, a constrained transaction is guaranteed to perform, assuming that it does not contain a condition that renders it incapable of completion. To ensure that it completes, the processor (eg CPU) will perform the operation may take certain measures. For example, if a constrained transaction has an abort condition, the CPU might temporarily:
[0352] (a) inhibit out-of-order execution;
[0353] (b) inhibit other processors from accessing the conflicting storage locations;
[0354] (c) induce random delays in interrupt processing; and/or
[0355] (d) invoke other measures to facilitate successful completion.
[0356] To summarize, the processing of a transaction is restricted as follows:
[0357] • If already in TX-restricted mode, an operating restriction exception is recognized.
[0358] • If the TND (Depth of the Transaction Nesting)> 0, execution proceeds as if unconstrained transaction
[0359] effective control F set to zero
[0360] effective PIFC remains unchanged
[0361] Allows Outside Unrestricted TX to call the function of services that may or may not use Restricted TX.
[0362] • If current TND = 0:
[0363] Transaction diagnostic block address is invalid
[0364] - In the specified TDB-instruction stored in abort
[0365] Transaction-abort PSW address set of TBEGINC
[0366] - Not the next sequential instruction
[0367] GRSM-designated General-record pairs saved in a model-dependent location not accessible by program
[0368] The optionally formed Transaction symbol (from D2 operand). The transaction symbol is a transaction identifier. It can be the same as the storage operand address or another value.
[0369] • Effective A = TBEGINC A & A any exterior
[0370] • TND incremented
[0371] o If TND transitions from 0 to 1, CPU enters restricted TX mode
[0372] otherwise, CPU remains in unrestricted TX mode
[0373] • Instruction complete with CC0
[0374] • Exceptions:
[0375] the exception specification (PIC (Program Code Interrupt) 0006) if field B i is non-zero
[0376] Special operation exception (PIC 0013 hex) if running transaction control (CR0.8) is zero
[0377] Transaction restriction exception (PIC 0018 hex) if issued in restricted TX mode
[0378] the operation exception (PIC 0001), if the constrained transaction execution facility is not installed
[0379] o Execute exception (PIC 0003) if the instruction is the target of an instruction type execution
[0380] abort code 13 if nesting depth exceeded
[0381] • Abort conditions in restricted operation:
[0382] Abort PSW points to instruction TBEGINC
[0383] - Not the instruction that follows it
[0384] - Abort condition causes entire TX to be re-driven
[0385] * Without fail path
[0386] CPU takes special measures to ensure successful completion in re-drive Violation
[0387] o Assuming no conflicts persist, interrupt, or constrain, the transaction is assured of eventual completion.
[0388] • Restriction Violation:
[0389] o PIC 0018 hex - indicates operation restriction violation
[0390] Or, transaction is executed as if unconstrained
[0391] As described above, in addition to restricted transaction processing, which is optional, in one embodiment, the transaction facility also provides for unrestricted transaction processing. More details on the processing of unconstrained transactions, and in particular the processing associated with a TBEGIN instruction are described with reference to figure 12. Execution of the TBEGIN instruction causes the CPU to either enter or to remain in execution mode transactional unrestricted. The CPU (i.e. the processor) that executes TBEGIN executes the logic in Figure 12.
[0392] With reference to figure 12, based on the execution of the TBEGIN instruction, a serialization function (described above) is performed, STEP 1200. After the serialization is performed, a determination is made as to whether an exception is recognized, SEARCH 1202. If so, then the exception is handled, STEP 1204. For example, a special exception operation is recognized and the operation is suppressed if transactional execution control, 8 bits of control register 0, is zero. Also, a specification exception is recognized and the operation is suppressed if the interrupt filtering control program, bits 14-15 of the I2 field of the instruction, contains the value 3; or the first address of the operand does not designate a double word boundary. An exception operation is recognized and the operation is suppressed, if the transaction execution facility is not installed in the configuration; and an exception is recognized and executing the operation is suppressed if the TBEGIN is the target of an execution of the type of instructions. Also, if the CPU is in transactional constrained execution mode, then a constrained operation exception program exception is recognized and the operation is suppressed. Also, if the transaction nesting depth, when incremented by one, would be greater than a model-dependent maximum transaction nesting depth, the transaction is aborted with abort code 13.
[0393] Still further, when the Bi field of the instruction is non-zero and the CPU is not in transaction execution mode, i.e., transaction nesting depth is zero, then the accessibility store for the first operand is determined. If the first operand cannot be accessed for the stores, then an access exception is recognized and the operation is either aborted, suppressed, or terminated, depending on the specific exception access condition. Also, any storage mode by change to the first operand is recognized. When the Bi field is non-zero and the CPU is already in transaction execution mode, it is unpredictable if store accessibility to the first operand is determined, and PER store change events are detected for the first operand. If the Bi field is zero, then the first operand is not accessed.
[0394] In addition to exception control, a determination is made as to whether the processor is in transaction execution mode (i.e. transaction nesting depth is zero), MESSAGE 1206. If the CPU is not in transaction execution mode, then the contents of the general register selected pairs are saved, STEP 1208. In particular, the contents of the general register pairs designated by the general register save mask are saved in a location dependent model that is not directly accessible by the program.
[0395] In addition, a determination is made as to whether the Bi field of the instruction is zero, MESSAGE 1210. If the Bi field is not equal to zero, the first address of the operand is placed in the diagnostic transaction address block , STEP 1214, and the transaction diagnostic block address is valid. Also, the transaction abort PSW is defined from the contents of the current PSW, STEP 1216. The instruction address of the transaction abort PSW designates the next sequential instruction (ie, the instruction after the outermost TBEGIN).
[0396] In addition, a determination is made of the effective value of the (A) control to allow AR modification, bit 12 of field I2 of the instruction, STEP 1218. The effective control A is the logic AND of the A control in the TBEGIN instruction to the current level and for all exterior levels. In addition, an effective value of the floating point operation allow control (F), bit 13 of the I2 field of the instruction, is determined, STEP 1220. The effective control F is the logic AND of the control F in the TBEGIN instruction to the current level and for all exterior levels. In addition, an effective value of the program interrupt filtering control (PIFC), bits 14-15 of the I2 field of the instruction, is determined, STEP 1222. The effective value of public finance control is the largest value in the TBEGIN instruction for the current level through all exterior levels.
[0397] In addition, a value of one is added to the transaction nesting depth, STEP 1224, and the instruction ends with the creation of condition code 0, STEP 1226. If the transaction nesting depth transitions from zero to one , the CPU enters unrestricted transactional execution mode; otherwise, the CPU remains in unrestricted transactional execution mode.
[0398] Returning to inquiry 1210, ifBi is equal to zero, then the transaction diagnostic block address is invalid, STEP 1121, and processing continues with step 1218. Likewise, if the CPU is in transactional execution mode, At MESSAGE 1206, processing continues as step 1218.
[0399] Resulting TBEGIN Execution Condition Code include, for example:
[0400] 0 Transaction initiation successful
[0401] 1
[0402]2
[0403] 3
[0404] Program exceptions include, for example:
[0405] • Access (store, first operand)
[0406] Operation (transactional execution facility is not installed)
[0407] • Special Operation
[0408] • Specification
[0409] Transaction restriction (due to restricted instruction)
[0410] In one embodiment, the exception to the check provided above may variably occur. A particular order for exception checking is as follows:
[0411] • Exceptions with the same priority as the priority of program interrupt conditions for the general case.
[0412] • Specification exception due to reserved PIFC value.
[0413] • Specification exception due to first address operating not on a double word boundary.
[0414] • Access exception (when the Bi field is non-zero).
[0415] • Abort due to transaction exceeding maximum nesting depth.
[0416] • Condition Code 0 due to normal completion.
[0417] Notes:
[0418] 1. When the Bi field is non-zero, the following applies:
[0419] • A transaction accessible diagnostic block (TDB), must be provided when an outermost transaction is started - even if the transaction does not abort.
[0420] • Since it is unpredictable whether the TDB's accessibility is tested for nested transactions, an accessible TDB must be provided by any nested TBEGIN statement.
[0421] • The performance of any TBEGIN where the Bi field is non-zero, and the performance of any abort processing that occurs on a transaction that was initiated by an ultra-peripheral TBEGIN where the Bi field is non-zero, may be slower than when the Bi field is zero.
[0422] 2. Records designated to be saved by the general register save mask are only restored, in one embodiment, if the transaction is aborted, not when the transaction normally terminates by means of an edge transaction. Only the GRSM-assigned records of the transaction's outermost BEGIN instructions are restored on abort.
[0423] Field h must designate all record pairs that provide input values that are changed by the transaction. Thus, if the transaction is aborted, the input register values will be restored to their original contents when the interrupt handler is entered.
[0424] 3. The transaction BEGIN (TBEGIN) instruction shall be followed by a branch conditional instruction which will determine whether the operation has started successfully.
[0425] 4. If a transaction is aborted due to conditions that do not result in an interrupt, the instruction designated by the abort PSW transaction is given control (ie, the instruction after the outermost transaction BEGIN (TBEGIN)). In addition to the condition code set by the transaction BEGIN (TBEGIN) statement, condition codes 1-3 are also set when a transaction is aborted.
[0426] Therefore, the sequence of instructions After the outermost operation BEGIN (TBEGIN) of instructions must be able to accommodate all four condition codes, even though the TBEGIN instruction code sets only 0 in this example.
[0427] 5. In most models, improved performance can be realized, both on TRANSACTION BEGIN and when the transaction is aborted, by specifying the minimum number of records needed to be saved and restored in the general record save mask.
[0428] 6. While in unrestricted transactional execution mode, a program may call a service function that can change access registers or floating-point registers (including the floating-point control register). Although such a service routine can save changed records on input and restore them on output, the operation can be canceled before the routine exits normally. If the calling program does not provide for the preservation of these registers, while the CPU is in unrestricted transactional execution mode, it may not be able to tolerate changing the service function of the registers.
[0429] To avoid inadvertently changing access registers while in unrestricted transactional execution mode, the program can set the allow control AR modification, bit 12 of field I2 of the transaction BEGIN instruction, to zero. Likewise, to prevent inadvertent change of floating-point registers, the program can set the Allow Floating-Point Operation control, bit 13 of field I2 of the TBEGIN instruction, to zero.
[0430] 7. Program exception conditions recognized during the execution of the TRANSACTION BEGIN (TBEGIN) instruction are subject to effective program interrupt filtering control set to any outside TBEGIN instructions. Program exception conditions recognized during execution of the outermost TBEGIN instruction are not subject to filtering.
[0431] 8. To update multiple storage locations in a serialized manner, conventional code sequences may employ a block word (semaphore). If (a) transactional execution is used to implement updates from multiple storage locations, (b) the program also provides a "fall-back" path to be invoked if the transaction aborts, and (c) the fallback path employs a lock word, then the transactional execution path must also test the availability of the lock, and, if the lock is not available, terminate the transaction through the TRANSACTION END statement and branch to the fall back path. This ensures consistent access to serialized resources, regardless of whether they are transactionally updated.
[0432] Alternatively, the program could abort if the lock is not available, however abort processing can be significantly slower than simply terminating the transaction via TEND.
[0433] 9. If the effective program interrupt filtering control (PIFC) is greater than zero, the CPU filters most program interrupts from data exception. If the effective allow floating point control operation (F) is zero, the data exception code (DXC) will not be set in the floating point control register as a result of an abort due to a program exception exception condition of data. In this scenario (filtering and effective control applies to F is zero), the only place the DXC is inspected is in the TBEGIN- specified TDB. If the program's interrupt handler is to inspect the DXC in such a situation, general register Bi must be non-zero such that a valid transaction diagnostic block (TDBA) address is set.
[0434] 10. If a PER storage change or zero address detection condition exists for the TBEGIN-specifled TDB of the outermost TBEGIN instruction, and PER event suppression does not apply, the PER event is acknowledged during instruction execution, causing as soon as the transaction aborts immediately, regardless of whether any other abort conditions exist.
[0435] In one embodiment, the TBEGIN instruction implicitly sets the transaction aborted address to the next sequential instruction following the TBEGIN. This address is intended to be a conditional branch instruction that determines whether or not to branch depending on the condition code (CC). A successful TBEGIN sets CCO, whereas an aborted transaction sets CCl, CC2, or CC3.
[0436] In one embodiment, the TBEGIN instruction provides an optional storage operand designating the address of a diagnostic transaction block (TDB), in which information is stored if the transaction is aborted.
[0437] In addition, it provides an immediate operand including the following:
[0438] A register save general mask (GRSM) indicating which pairs of general registers are to be saved at the beginning of transactional execution and restored if the transaction is aborted;
[0439] A bit (A) to allow transaction abort if transaction modifies access registers;
[0440] Bit (F) to allow transaction abort if transaction attempts to execute floating point instructions; and
[0441] Program interrupt filtering (PIFC) that allows individual transaction levels to ignore the actual presentation of a program interrupt if the transaction is aborted.
[0442] Controls A, F, and Public Finance Controls can be different at various nesting levels and restored to the previous level when internal transaction levels are ended.
[0443] In addition, TBEGIN (or in another embodiment, TBEGINC) is used to form a transaction symbol. Optionally, the witness can be combined with a signal formed by the TEND instruction. For each TBEGIN (or TBEGINC) instruction, as an example, a signal is formed from the first address of the operand. This sign can be formed regardless of whether the base register is zero (unlike the definition of the TDB address, which only occurs when the base register is different from zero). For each TRANSACTION END statement executed with a non-zero base register, a similar symbol is formed from its storage operand. If the signs are not equal, a program exception can be recognized to alert the program of an unpaired instruction.
[0444] matching token provides a mechanism intended to improve software reliability by ensuring that a TEND statement is properly paired with a TBEGIN (or TBEGINC). When a TBEGIN instruction is executed at a particular nesting level, a signal is formed from the address of the storage operand that identifies this case of a transaction. When a corresponding TEND instruction is executed, a signal is formed from the instruction store operand address, and the processor compares the signal to start level overlap with the final signal. If the signs are not equal, an exception condition is recognized. A model can implement token matching for only a certain number of overlapping levels (or no nesting levels at all). The signal may not involve all bits of the storage operand address, or the bits may be combined through hashing or other methods. A symbol can be formed by the TBEGIN instruction even if its storage operand is not accessed.
[0445] To summarize, an unconstrained processing operation is as follows:
[0446] If TND = 0:
[0447] o If Bi^0, diagnostic transaction block address set from first operand address.
[0448] PSW transaction abort set for next sequential instruction address.
[0449] The general record pairs designated by the h field are saved in location dependent modeling.
[0450] Not directly accessible by program
[0451] Effective controls PIFC, A & F calculated
[0452] the Effective A = TBEGIN A & A any outside
[0453] the effective F = TBEGIN F & F any outside
[0454] Effective PIFC = max (TBEGIN CIFP, any outside CIFP)
[0455] Transaction nesting depth (TND) incremented
[0456] • If TND transitions from 0 to 1, CPU enters transactional execution mode
[0457] • Condition Code set to zero
[0458] o When following TBEGIN instruction receives control:
[0459] - TBEGIN success indicated by CC0
[0460] - Aborted transaction indicated by non-zero CC
[0461] • Exceptions:
[0462] Abort code 13 if nesting depth exceeded
[0463] Access exception (one of several PICs) if the field B i is non-zero, and the store operand cannot be accessed by a store operation
[0464] o Execute exception (PIC 0003) if the TBEGIN instruction is the target of an instruction type execution
[0465] o Operation exception (PIC 0001), if transactional execution facility is not installed
[0466] the PIC 0006 if any
[0467] - PIFC is invalid (value of 3)
[0468] - address of second non-doubleword aligned operand
[0469] PIC 0013 hex if transactional control execution (CR0.8) is zero
[0470] PIC 0018 hex if issued in restricted TX mode
[0471] As indicated above, a transaction, whether constrained or unconstrained, can be terminated by a TRANSACTION END (TEND) statement. More details on processing a transaction end (TEND) instructions are described with reference to figure 13. The CPU (that is, the processor) executing the TEND executes the logic of figure 13.
[0472] With reference to figure 13, initially, based on the processor obtain (eg, fetch, receive, etc.), the TEND instruction, various exception checking is performed, and if there is an exception, FIND 1300, in then the exception is handled, STEP 1302. For example, if the TRANSACTION END is the target of an execution of the statement type, the operation is suppressed and a execute exception is recognized; and a special exception operation is recognized and the operation is suppressed if the transactional execution control, 8 bits of CR0, is zero. Furthermore, an exception is recognized for the operation and the operation is suppressed, if the transaction execution facility is not installed in the configuration.
[0473] Going back to the inquiry of 1300, if an exception is not recognized then the transaction nesting depth is reduced (eg by one), STEP 1304. The determination is made as to whether the transaction nesting depth is zero after decrement, RESEARCH 1306. If transaction nesting depth is zero, then all storage accesses done by the transaction (and other transactions within the transaction nest, if any, of which this transaction is a part) are committed, STEP 1308. Additionally, the CPU leaves the transactional execution mode, STEP 1310, and completes instructions, STEP 1312.
[0474] Going back to inquiry 1306, if the transaction nesting depth is not equal to zero, then the TRANSACTION END statement just completed.
[0475] If the CPU is in transaction execution mode at the start of the operation, the condition code is set to 0; otherwise, the condition code is set to 2.
[0476] Note that the effective allow floating point operation (F) control, allow modification AR (A) control and program interrupt control (PIFC) filter are reset to their respective values before the operation begins the instruction that started the level being ended. Also, a serialization function is performed after the operation is completed.
[0477] The PER fetch instruction and transaction end events that are acknowledged on completion of the ultra peripheral TRANSACTION END instruction do not result in the transaction being aborted.
[0478] In one example, the TEND instruction also includes a B2 base field and a D2 shift field, which are combined (eg, added) to create a second operand address. In this example, corresponding signal can be realized. For example, when B2 is non-zero, the bits selected from the second address of the operand are compared with a transaction signal formed by the corresponding TBEGIN. If there is a mismatch, it is not an exception (eg PIC 0006).
[0479] In addition to the above, a transaction can be stopped, implicitly or explicitly by an abort transaction instruction. Aborting a transaction by TABORT or otherwise includes performing a series of steps. An example of interrupt processing steps in general is described with reference to Figure 14. If there is a difference in processing based on whether the abort is initiated by TABORT or otherwise, it is indicated in the description below. In one example, a processor (e.g. CPU) is executing the logic of figure 14.
[0480] Referring to Figure 14, initially, based on the execution of the TABORT instruction or an implicit abort, non-transactional store accesses made while the CPU was in transactional execution mode are compromised, Step 1400. Other stores (eg, stores transactional) made while the CPU was in transactional execution mode are discarded, STEP 1402.
[0481] CPU leaves transactional execution mode, STEP 1404, and subsequent stores occur non-transactional. The current PSW is replaced as transaction contents aborted PSW, except that the condition code is set as described above (apart from the situation that follows, in which if TDBA is valid but the lock is unreachable, then CC = 1 ), STEP 1406. As a later part or to abort processing, transaction processing branches abort the specified local PSW to perform an action. In an example where the operation is a constrained operation, the location is the TBEGINC instruction and the action is re-execution of that instruction; and in another example where the transaction is an unconstrained transaction, the location is the instruction after TBEGIN, and the action is the execution of that instruction, which can be, for example, a branch to an interrupt handler.
[0482] A determination is then made as to whether the operation diagnostic block address is valid, SURVEY 1408. When the operation diagnostic block address is valid, the diagnostic information to identify the reason for aborting and the General register contents are stored in the transaction diagnostic block specified-TBEGIN, STEP 1410. The stored TDB fields and conditions under which they are stored are as described above with reference to the transaction diagnostic block.
[0483] If the transaction diagnostic block address is valid, but the block has become inaccessible, after executing the outermost TBEGIN instruction, the block is not accessible, and condition code 1 applies.
[0484] For transactions that are aborted due to program exception conditions that result in an interrupt, the program interrupt TDB is stored.
[0485] Returning to inquiry 1408, if transaction diagnostic block address is not valid, unspecified-TBEGIN TDB are stored and condition code 2 or 3 applies, depending on the reason for abort.
[0486] In addition to the above, transaction nesting depth is set equal to zero, STEP 1412. In addition, any general register pairs designated to be saved by the outermost TBEGIN instruction are restored, STEP 1414. General register pairs that were not assigned to be saved by the ultra peripheral TBEGIN instruction are not restored when a transaction is aborted.
[0487] In addition, a serialization function is performed, STEP 1416. A serialization function or operation includes completing all previous storage conceptually accesses (and, for the z/Architecture, as an example, the related bit-reference bit settings and change) by the processor, as noted by other CPUs and the I/O subsystem, before accessing the conceptually subsequent storage (and related reference bit definitions and bit change) occurs. Sequence serialization effects the entire CPU accesses storage and storage keys, except for those associated with the ART table entry and attractive DAT table entry.
[0488] As noted by a processor in transactional execution mode, serialization operates normally (as described above). As noted by other CPUs and the I/O subsystem, a serialization operation performed with a CPU in transactional execution mode occurs when the processor exits transaction execution mode, either as a result of an edge transaction instruction that decreases transaction nesting depth to zero (which terminates normally) or as a result of the operation being aborted.
[0489] For abort processing initiated except by TABORT, if the transaction is aborted due to an exception condition that results in an interrupt, MESSAGE 1418, interrupt codes or parameters associated with the interrupt are stored in the corresponding assigned storage locations to the interrupt type, STEP 1420. Also, the current PSW, as stated above, is stored in the old interrupt PSW, STEP 1422. Thereafter, or if the operation was not aborted due to an exception condition, which resulted in an interrupt, the instruction ends with the condition code of zero.
[0490] In addition to the above, in an embodiment for executing the z/Architecture interpretive, when the processor is in transactional execution mode, and a guest condition occurs that typically result in trap codes 4, 12, 44, 56, 64, 68 or 72, the interception does not occur. Instead, the CPU remains in interpretive execution mode, and the abort conditions are indicated to the guest as follows:
[0491] • For an unconstrained transaction, the transaction is aborted due to a restricted instruction (abort code 11). If a concurrent PER event has been detected and the CPU is PER enabled, a program interrupt occurs with interrupt code 0280 hex.
[0492] • For a constrained operation, a transaction constraint exception is recognized. If a concurrent PER event has been detected and the CPU is PER enabled, a program interrupt occurs with interrupt code 0298 hex.
[0493] When a transaction is aborted due to a program exception condition, program interrupt filtering can inhibit the presentation of an interrupt. For program interruptions that could result in interception, filtering also inhibits interception.
[0494] As indicated above, according to one aspect, when a program initiates an unconstrained transaction (i.e., a transaction for which an interrupt handler recovery routine is provided), the program may designate a storage location in which diagnostic information is to be written if the transaction aborts. Diagnostic information can also be provided if a transaction is aborted due to a program interrupt or if the Abort results in an interpretive execution trap, such as the program interrupt interrupt.
[0495] In one embodiment, based on an abort of a transaction, diagnostic information is provided in a transaction diagnostic block (TDB). Information includes, for example: transaction nesting depth; transaction abort code; conflict token (for transactions that are aborted due to conflicts); aborting transaction instruction address; program interrupt parameters for operations that are aborted due to filtered program exception conditions; dependent diagnostic information model; general purpose records at the time of Abort; and/or other information as described above with reference to figure 9.
[0496] Zero, one or two TDBs may be stored in an abort, including: a program-specified TDB (aka, TBEGIN-TDB), which may or may not be present for an unconstrained transaction; a program interrupt TDB provided to the control program when a transaction is aborted due to an unfiltered program exception condition (that is, a condition that actually results in a program interrupt); and/or a TDB interception provided to a host program (eg operating system) when a transaction is aborted due to certain interception conditions.
[0497] One embodiment of the processing associated with storing zero or more TDBs is described with reference to Figure 15. This logic is performed by a processor, such as the processor, upon detection of an interrupt condition.
[0498] Referring to Figure 15, initially an abort (ie, an abnormal end) of a transaction is detected, STEP 1500. From there, a determination is made as to whether a valid Transaction Diagnostic Block (TDBA) address is was specified, SURVEY 1502. For example, this is the address of a valid transaction diagnostic block specified by a TBEGIN instruction (eg Bi of TBEGIN > 0). If a valid TDBA is provided, the information is stored in the TDB specified by the program, as described above, step 1504.
[0499] Then, or if a valid TDBA is not provided, a new determination is made as to whether the abort condition is due to an interrupt, SURVEY 1506. If so, then the information is stored in the interrupt program TDB , as indicated above, STEP 1508.
[0500] Then, or if the abort is not due to a program interrupt, a determination is made as to whether the abort resulted in an intercept, SURVEY 1510. If the abort did not result in an intercept, this transformation is complete. Otherwise, the information is stored in an intercept TDB, as described above, step 1512. This completes processing.
[0501] As indicated, one or more TDBs or no TDBs at all can be stored as a result of an abort. However, each TDB that is stored provides abort-related diagnostic information that can facilitate debugging.
[0502] In addition to providing comprehensive diagnostic information as described above, it also provides an efficient means of updating multiple, adjacent objects in memory without classical serialization (course grain), such as locking, which provides a potential for significant improvement. multiprocessor performance. That is, multiple, adjacent objects are updated without applying the more of course grain access to the ordering store that is provided through classical techniques such as locks and semaphores. Speculative execution is provided without hard recovery setup, and constrained operations are offered for simple, small-footprint upgrades.
[0503] Transactional execution can be used in a variety of scenarios, including, but not limited to, partial inline, speculative processing, and blocking avoidance. In partial inline, the partial zone to be included in the executed path is wrapped in TBEGIN/TEND. TABORT can be included to revert to a side-exit state. For speculation, as in Java, nullchecks on referenced-from pointers can be delayed to the loop edge using a transaction. If the pointer is null, the transaction can safely abort using TABORT, which is included within TBEGIN/TEND.
[0504] As per blocking avoidance, an example of its use is described with reference to Figures 16A-16B and the code fragment provided below.
[0505] Fig. 16A shows a doubly linked list 1600 of a plurality of row elements 1602A-1602d. A new row element 1602e is to be inserted into the doubly linked list of row elements 1600. Each row element 1602A-1602e includes a forward pointer 1604A-1604e and a backward pointer 1606a-1606e. As shown in Fig. 16B, to add row element 1602e between row elements 1602b and 1602c, (1) backward pointer 1606e is set to point to row element 1602b, (2) forward pointer 1604e is set to point to row row element 1602c, (3) backward 1606c pointer is set to point to row element 1602e, and (4) forward 1604b pointer is set to point to row element 1602e.
[0506] An example code fragment corresponding to figures 16A-16B is below:
[0507] * RL - address of the new queue element to be inserted.
[0508] * R2 - insertion point address; new element is inserted before the element pointed to by R2.
[0509] NEW USING QEL, Rl
[0510] CURR USING QEL, R2
[0511] LHI R15, repeat count 10 Load.
[0512] LOOP TBEGIN TDB, X'COOO 'Begin transaction (save RGs 0-3)
[0513] JNZ ABORTED Nonzero CC means aborted.
[0514] LG R3, CURR.BWD Point to previous element.
[0515] PREV USING QEL, R3 Make it addressable.
[0516] STG Rl, PREV.FWD previous update. ptr forward.
[0517] STG Rl, curr Update CURR.BWD. ptr backwards.
[0518] STG R2, NEW.FWD Update new ptr forward.
[0519] STG R3, NEW.B WD New update ptr backwards.
[0520] TEND transaction End.
[0522] ABORTED DO NOT TRY CC3: abort Nonretryable.
[0523] JCT R15, LOOP transaction Repeat a few times.
[0524] J NO REPET No joy after 1 Ox; do it the hard way.
[0525] In an example, if the transaction is used for lock elision, but the fallback path uses a lock, the operation is at least fetching the lock word to see that it is available. The processor guarantees that the transaction is aborted if another CPU accesses the non-transactional lock.
[0526] As used herein, storage, central storage, main memory, memory and main memory are used interchangeably, unless otherwise indicated, implicitly or explicitly by usage. Further, although in one embodiment, delaying effectively includes delaying committing transactional stores to main memory until the completion of a selected operation; In another embodiment, an effective delaying operation includes allowing transactional updates to memory but keeping old values and restoring memory to old values on abort.
[0527] As will be appreciated by one skilled in the art, one or more aspects may be embodied as a system, method or computer program product. Thus, one or more aspects may take the form of a fully hardware embodiment, a fully software embodiment (including firmware, resident software, microcode, etc.), or an embodiment of the combination of hardware and software that may all aspects, generally , be referred to herein as a "circuit", "module" or "system". In addition, one or more aspects may take the form of a computer program product embedded in one or more computer readable means(s) of having computer readable program code embedded therein. longer than the length of the field to be stored.
[0551] Certain information units are being at an integral limit in storage. A boundary is called integral for a unit of information when its storage address is a multiple of the unit's length in bytes. Special names are given to fields of 2, 4, 8, 16, and 32 bytes on an integral boundary. The halfword is a group of two consecutive bytes on a two-byte boundary and is the basic building block of instructions. A word is a group of four consecutive bytes on a four-byte boundary. A double word is a group of eight consecutive bytes on an eight-byte boundary. A quadword is a group of 16 consecutive bytes on a 16-byte boundary. An octoword is a group of 32 consecutive bytes on a 32-byte boundary. When storage addresses designate halfwords, doublewords, quadwords, and octowords, the binary representation of the address contains one, two, three, four, five, or more trailing zero bits, respectively. The instructions are to be over-byte two integral bounds. The storage operands of most instructions have no alignment boundary requirements.
[0552] On devices that implement separate caches for instructions and data operands, a significant delay can be experienced if the program stores in a cache line from which instructions are later fetched, regardless of whether the store changes the instructions that are subsequently sought.
[0553] In one example, embodiments may be practiced by software (sometimes referred to internal licensed code, firmware, microcode, Mili-code, Peak code and the like, any of which would be consistent with one or more embodiments). Referring to Figure 18, software program code that embodies one or more aspects may be accessed by the host system 5000 processor 5000 from 5011 long-term storage media devices, such as a CD-ROM drive, drive tape or hard disk. The software program code may be embedded in any of a variety of known media for use with a data processing system, such as a floppy disk, a hard disk, or a CD-ROM. The code may be distributed on such media, or may be distributed to users from computer memory 5002 or storage of a computer system over a network 5010 to other computer systems for use by users of such other systems.
[0554] Software program code includes an operating system that controls the function and interaction of various computer components and one or more application programs. Program code is normally paged from the media storage device 501 1 to the relatively higher speed computer storage 5002, where it is available for processing by the 5001 processor. The techniques and methods for containing software program code in memory, on physical media and/or distribution of software code over networks are well known and will not be discussed further here. Program code, when created and stored on a material medium (including, but not limited to, electronic memory modules (RAM), flash memory, compact discs (CDs), DVDs, magnetic tape, and the like is often referred to as a "product of computer program." The form of the computer program product is typically read by a processing circuit, preferably a computer system for execution by the processing circuit.
[0555] Figure 19 illustrates a representative server or workstation hardware system in which one or more embodiments may be practised. The system 5020 of Figure 19 comprises a representative base computer system 5021, such as a personal computer, workstation or server, including optional peripheral devices. Computer system 5021 includes base of one or more processors 5026 and a bus employed to connect and allow communication between processor(s) 5026 and other components of system 5021 in accordance with known techniques. The bus connects the processor to 5025 5026 memory and 5027 long term storage which can include a hard disk drive (including any of the magnetic media, CD, DVD and flash memory for example) or a tape drive for example. The 5021 system may also include a user interface board, which connects the 5026 microprocessor via the bus to one or more interface devices, such as a 5024 keyboard, a 5023 mouse, a 5030 printer/scanner, and or other interface devices. which can be any UI device such as a touchscreen, digitized input keyboard, etc. The bus also connects a 5022 display device, such as an LCD screen or monitor, to the 5026 microprocessor via a video adapter.
[0556] The 5021 system can communicate with other computers or computer networks through a network adapter capable of communicating with a 5028 network Example of a 5029 network. Adapters are communication channels, Token Ring, Ethernet or modems. Alternatively, system 5021 may communicate using a wireless interface, such as a CDPD (cellular digital packet data) card. System 5021 may be associated with such other computers on a local area network (LAN) or wide area network (WAN), or system 5021 may be a client on a clientI/Oervidor in agreement with another computer, etc. All of these configurations, as well as the appropriate communications hardware and software, are known in the art.
[0557] Fig. 20 illustrates a data processing network of 5040 in which one or more embodiments may be practised. Data processing network 5040 may include a plurality of individual networks, such as a wireless network and a wired network, each of which may include a plurality of individual workstations 5041, 5042, 5043, 5044. In addition As those skilled in the art will appreciate, one or more local area networks may be included, if it is a LAN it may comprise a plurality of intelligent workstations coupled to a host processor.
[0558] Still referring to Figure 20, networks can also include mainframes or servers, such as a gateway computer (5046 client server) or application server (5048 remote server that can access a data repository and can also be accessed directly). from a 5045 workstation). A 5046 gateway computer serves as an entry point into each individual network. A gateway is needed when connecting one network protocol to another. Gateway 5046 may preferably be coupled to another network (Internet, e.g. 5047) via a communications link. The 5046 gateway can also be directly coupled to one or more workstations 5041, 5042, 5043, 5044 using a communications link. The computer's gateway can be implemented using an IBM eServer System z server available from International Business Machines Corporation.
[0559] With reference simultaneously to figure 19 and figure 20, software programming code 5031 that may incorporate one or more embodiments may be accessed by the processor 5026 of the long-term storage media system 5020 5027, such as a CD-ROM drive. ROM or hard disk. The programming software code may be embedded in any of a variety of known media for use with a data processing system, such as a floppy disk, a hard disk, or a CD-ROM. The code may be distributed on such media, or it may be distributed to users 5050, 5051 from the memory or storage of one computer system over a network to other computer systems for use by users of such other systems.
[0560] Alternatively, programming code may be embedded in memory 5025, and accessed by processor 5026 using the processor bus. Such programming code includes an operating system that controls the function and interaction of various computer components and one or more application programs 5032. The program code is normally paged from storage media 5027 to high-speed memory 5025 where is available for processing by the 5026 processor. The techniques and methods of containing programming code for the software in memory, on physical media, and/or distributing software code over networks are well known and will not be discussed further here. . Program code, when created and stored on a material medium (including, but not limited to, electronic memory modules (RAM), flash memory, compact discs (CDs), DVDs, magnetic tape, and the like is often referred to as a "product of computer program." The form of the computer program product is typically read by a processing circuit, preferably a computer system for execution by the processing circuit.
[0561] The cache that is most readily available to the processor (typically faster and smaller than other processor caches) is the lowest (LI or level one) cache and the main store (main memory) is the cache of highest level (L3 if there are 3 levels). The lower-level cache is often divided into an instruction cache (I-Cache) holding machine instructions to be executed and a data cache (D-Cache) holding data operands.
[0562] With reference to Fig. 21, an exemplary embodiment is described processor for processor 5026. Typically one or more cache levels of 5053 are used to buffer memory blocks in order to improve processor performance. The 5053 cache is a high-speed buffer holding cache lines of memory data that are likely to be used. Typical cache lines are 64, 128, or 256 bytes of memory data. Separate caches are often used for caching instructions rather than caching data. Cache coherence (synchronization of lines of in-memory copies and caches) is often provided by various "snoop" algorithms well known in the art. A processor system's 5025 main memory storage is often referred to as a cache. On a processor system with 4 levels of 5053 cache, the 5025 main memory is sometimes referred to as the 5 (L5) level cache, as it is typically faster and only takes up a portion of non-volatile storage (DASD). , tape, etc.) that is available for a computer system. The main store 5025 "caches" pages of data paged in and out of main memory 5025 by the operating system.
[0563] A counter program (instruction counter) 5061 keeps track of the address of the current instruction to be executed. A program counter on the az/Architecture processor is 64 bits and can be truncated to 31 or 24 bits to support earlier addressing limits. A program counter is typically embodied in a computer's PSW (program status word) in such a way that it persists during context switching. In this way, a running program, having a program counter value, can be interrupted, for example, the operating system (context change from the program environment to the operating system environment). The program PSW holds the value of the program counter while the program is not active, and the program counter (in PSW) of the operating system is used while the operating system is running. Typically, the program counter is incremented by a value equal to the number of bytes in the current instruction. RISC (Reduced Instruction Set Computing) instructions are generally fixed-length, while CISC (Complex Instruction Set Computing) instructions are typically variable-length. IBM z/Architecture instructions are CISC instructions having a length of 2, 4, or 6 bytes. Program counter 5061 is modified by either a context switch operation or a branch taken operation of a branch instruction, for example. In a context switch operation, the current program counter value is saved in the program status word, along with other state information about the program being executed (such as condition codes), and a new counter value. program is loaded pointing to an instruction of a new program module to be executed. A branch taken operation is performed in order to allow the program to make decisions or cycle within the program, loading the result of the branch instruction into program counter 5061.
[0564] Typically a 5055 fetch instruction is employed to obtain instructions on behalf of the 5026 processor. The fetch unit either fetches "next sequential instructions", target instructions from branch taken instructions, or first instructions of a program following a context switch. Modern instruction fetch units often employ prefetch techniques so speculatively that PREFETCHED instructions can be used prefetch instructions based on probability. For example, a fetch unit might fetch 16 bytes of instruction that include the next sequential instruction and additional bytes of more sequential instructions.
[0565] The instructions are then fetched by the processor 5026. In one embodiment, the fetched instruction(s) are passed to a send unit 5056 of the fetch unit. The dispatch unit decodes the instruction(s) and forwards information about the decoded instruction(s) to appropriate units 5057, 5058, 5060. An executing unit of 5057 will typically receive information about decoded arithmetic instructions from the instruction fetch unit 5055 and will perform arithmetic operations on operands according to the instruction's opcode. Operands are provided to the execution unit preferably 5057, either from memory 5025, 5059 or architected registers from a field immediately following the instruction to be executed. Execution results, when stored, are stored in memory 5025, registers 5059, or other machine hardware (such as control registers, PSW registers, and the like).
[0566] Virtual addresses are transformed into real addresses using dynamic address translation 5062 and optionally using access register translation 5063.
[0567] A 5026 processor typically has one or more units of 5057, 5058, 5060 to perform the instruction's function. Referring to Fig. 22A , an execution unit 5057 can communicate with 5081 architected general registers 5059, a decode/dispatch unit 5056, a load storage unit 5060, and another 5065 processor units via logical interface 5071. execution unit 5057 may employ various register circuits 5067, 5068, 5069 to contain the information that the arithmetic logic unit (ALU) 5066 will operate. The ALU performs arithmetic operations such as add, subtract, multiply, and divide, as well as logical functions such as and, or, and exclusive-or (XOR), rotate, and shift. Preferably, the ALU supports specialized operations that are design dependent. Other circuits may provide other 5072-architected facilities, including condition codes and recovery support logic, for example. Typically, the result of an ALU operation is performed on an output register circuit 5070 that can transmit the result of a variety of other processing functions. There are many arrangements of processor units, the present description is only intended to provide a representative understanding of an embodiment.
[0568] An ADD instruction for example would be executed in a 5057 execution unit having arithmetic logic and functionality while a floating point instruction for example would be executed in a floating point execution having specialized floating point capability. Preferably, an execution unit operates on operands identified by an execution instruction of a function defined opcode on the operands. For example, an ADD instruction may be executed by an execution unit 5057 on operands found in two registers 5059 identified by the register of instruction fields.
[0569] The 5057 execution unit performs arithmetic addition over two operands and stores the result in a third operand where the third operand can be a third register or one of two code registers. The execution unit preferably uses an arithmetic logic unit (ALU) 5066 which is capable of performing a variety of logic functions such as Shift, Rotate, AND, OR and XOR as well as a variety of algebraic functions including any of add, subtract , multiply, divide. Some 5066 ALUs are designed for scalar operations and some for floating point. Data can be either Big Endian (where the least significant byte is the highest in the byte address) or Little Endian (where the least significant byte is the smallest byte address) depending on the architecture. IBM z/Architecture is Big Endian. Signed fields can be sign and magnitude, 1's complement or 2's complement depending on architecture. A 2's complement number is advantageous in that the ALU does not need to design a capability since subtracting a negative value or a positive value in 2's complement only requires an addition within the ALU. Numbers are commonly described in shorthand, where a 12-bit field defines an address of a 4096-byte block and is commonly described as a 4 Kbyte (Kilo-byte) block, for example.
[0570] Referring to Figure 22B, branch instruction information for executing a branch instruction is typically sent to a branch unit 5058 which often employs a branch prediction algorithm such as a branch history table 5082 to predict the result of the branch before other conditional operations are complete. The current branch instruction target will be taken and speculatively executed before the conditional operations are complete. When conditional operations complete the speculatively executed branch instructions are completed or discarded based on the conditions of the conditional operation and the speculated results. A typical branch instruction can test condition codes and branch to a destination address If the condition codes meet the branch requirement of the branch instruction, a destination address can be calculated based on multiple numbers including those found in register fields or an immediate instruction field for example. Branch unit 5058 may employ an ALU 5074 that has a plurality of register input circuits 5075, 5076, 5077 and a register output circuit 5080. Branch unit 5058 may communicate with general registers 5059, 5056 decoding unit of dispatch or other 5073 circuits, for example.
[0571] Execution of a set of instructions can be interrupted for a variety of reasons including a context switch initiated by an operating system, a program exception or error causing a context switch, an I/O interrupt signal What causes a context switch or multiple activity from a plurality of programs (in a multi-threaded environment) -Threading, for example. Preferably, a context switch action saves state information about a currently running program and then loads state information about another program being called. State information can be saved in hardware registers or in memory, for example. Preference state information comprises a program counter value pointing to a next instruction to be executed, condition codes, memory translation information and architected register contents. Context switching activity may be performed by hardware circuits, application programs, operating system programs, or firmware code (microcode, pico-code, or licensed internal code (LIC)) alone or in combination.
[0572] A processor accesses instruction operands according to defined methods. The instruction may provide an immediate operand using the value of a part of the instruction, it may provide one or more register fields explicitly pointing to either general-purpose registers or special-purpose registers (floating-point registers for example). The instruction can use implicit registers identified by an opcode field as operands. The instruction can use memory locations for operands. The memory location of an operand can be provided by a register, an immediate field, or a combination of registers and an immediate field as exemplified by the long-shift /z facility architecture in which the instruction defines a base register, an index register, and an immediate field (displacement field), which are added together to give the address of the operand in memory, for example. Location here typically implies a location in main memory (main memory), unless otherwise noted.
[0573] Referring to Figure 22C, a storage access processor using a load/storage unit 5060. The load/store unit 5060 can perform a load operation by obtaining the address of the destination operand in memory 5053 and the loading the operand into a register 5059 or another location memory 5053, or it may perform a store operation, obtaining the address of the destination operand in memory 5053 and storing data obtained from a register or another location memory 5059 5053 at the target location operating in memory 5053. The load/store unit 5060 may be speculative and may access memory in a sequence that is out of order with respect to the instruction sequence, however the load/store unit of 5060 is to keep the appearance of programs that instructions were executed in order. Load/store unit 5060 can communicate 5084 with general registers 5059, decode/dispatch unit 5056, cache/memory interface 5053 or other elements 5083 and comprises various register circuits 5086, 5087, 5088 and 5089, ALUs 5085 and logic 5090 controller to calculate storage addresses and provide pipeline sequencing to keep operations in order. Some operations may be out of order, but the load/storage unit provides the functionality to do out of order operations in order to appear to the program as having been performed in order, as is well known in the art.
[0574] Preferably addresses an application program that "sees" are often referred to as virtual addresses. "logical addresses" and "effective addresses". These virtual addresses are virtual in that they are redirected to physical memory locations by one of a variety of dynamic address translation (DAT) technologies, including, but not limited to, simply prefixing a virtual address with an offset value, the virtual address translation via one or more translation tables, the translation tables preferably comprising at least a segment table and a page table alone or in combination, preferably the segment table which has a pointer to the page table entry. In the z/Architecture architecture, a translation hierarchy is provided including a region-first table, a region-second table, a region-third table, a segment table, and an optional page table. Address translation performance is often improved through the use of a translation lookup buffer (TLB) which comprises entries mapping a virtual address to an associated physical memory location. Entries are created when DAT translates a virtual address using translation tables. Subsequent use of the virtual address can then use the fast TLB entry, rather than the slow sequential translation table accesses. TLB content can be managed by a variety of replacement algorithms, including LRU (Least Recently Used).
[0575] In the case where the processor is a processor of a multi-processor system, each processor has the responsibility to keep shared resources, such as I/O, caches, TLBs and memory, linked by coherence. Typically, "snoop" technologies will be used to maintain cache coherence. In a Snoop environment, each cache line can be marked as being in any of a common state, a unique state, a changed state, an invalid state, and the like in order to facilitate sharing.
[0576] I 5054 I/O units (figure 21) provide the processor with means for attaching to peripheral devices, including tape, disk, printers, monitors, and networks, for example. I/O are often units presented to the computer program by software drivers. On mainframes such as IBM's System z, channel adapters and open systems adapters are mainframe I/O units that provide communications between the operating system and peripheral devices.
[0577] In addition, other types of computing environments may benefit from one or more aspects. As an example, an environment may include an emulator (e.g. software or other emulation mechanisms), where a particular architecture (including, for example, instruction execution, architected functions such as address translation, and the architected registers) or a subset thereof is emulated (for example, on a computer system that has a native processor and memory). In such an environment, one or more emulator emulator functions may implement one or more embodiments, even though a computer running the emulator may have a different architecture than the capabilities being emulated. As an example, in emulation mode, the specific instruction or operation being emulated is decoded, and an appropriate emulation function is built to implement the individual instruction or operation.
[0578] In an emulation environment, a host computer includes, for example, a memory to store instructions and data; a fetch unit instruction to fetch instructions from memory and optionally provide the local buffer for the fetched instruction; an instruction decoding unit for receiving the instructions obtained and for determining the type of instructions that have been read; and an instruction execution unit for executing the instructions. Execution may include loading data into a memory register; storing data back into the memory of a register; or perform some sort of arithmetic or logical operation, as determined by the decoding unit. In one example, each unit is implemented in software. For example, the operations being performed by the units are implemented as one or more subroutines in the emulator software.
[0579] More particularly, from a central unit, machine-architected instructions are used by programmers, typically today "C" programmers, often via a compiler application. These instructions stored on the storage medium can be executed natively on the IBM z/Architecture Server, or alternatively, machines running other architectures. They can be emulated on existing and future IBM® mainframe servers on and on other IBM machines (eg Power Systems servers and X System Servers). They can run on machines running Linux on a wide variety of machines using hardware made by IBM, Intel, AMD, and others. In addition to running on which hardware under z/Architecture, Linux can be used, as well as machines using emulation by Hercules, UMX, or FSI (Fundamental Software, Inc), on which an emulation mode is usually running. In emulation mode, emulation software is run by a native processor to emulate the architecture of an emulated processor.
[0580] The native processor typically runs emulation software comprising either firmware or a native operating system to perform the emulation of the emulated processor. The emulation software is responsible for fetching and executing instructions from the emulated processor architecture. Emulation software maintains an emulated program counter to keep track of instruction limits. Emulation software can fetch one or more emulated machine instructions at a time and convert one or more emulated machine instructions to a corresponding group of native machine instructions for execution by the native processor. These instructions can be cached in such a way that faster conversion can be achieved. Nevertheless, emulation software is to maintain the architectural rules of the emulated processor's architecture, so as to ensure operating systems and applications written for the emulated processor to operate correctly. In addition, the emulation software is to provide features identified by the architecture of the emulated processor including, but not limited to, control registers, general purpose registers, floating point registers, dynamic address translation function including segment tables and tables e.g. interrupt mechanisms, context switching mechanisms, time of day (TOD) clocks and interfaces architected to I/O subsystems so that an operating system or an application program designed to run on the emulated processor can be run on the native processor with the emulation software.
[0581] A specific instruction to be emulated is decoded, and a subroutine is called to perform the function of the individual instruction. An emulation software function emulating a function of an emulated processor is implemented, for example, in a "C" or driver subroutine, or any other method of providing a controller for specific hardware as will be within the ability of the skilled in the art after understanding the description of the preferred embodiment. Various software and hardware emulation patents, including but not limited to US Patent Letters No. 5,551, 013 entitled "Multiprocessor for Hardware Emulation", by Beausoleil et al.; and US Patent No. 6,009,261 entitled "Preprocessing Stored Target Routines for Emulating Incompatible Instructions on a Target Processor", by Scalzi et al; and Letters US Patent No. 5,574,873, entitled "Decoding Guest Instruction to Directly Access Emulation Routines that Emulate Client Instructions," by Davidian et al; and Letters US Patent No. 6,308,255 entitled "Symmetrical Multiprocessing Bus and Chipset Used for Coprocessor Support Allowing Non-Native Code to Run on a System", by Gorishek et al; and Letters US Patent No. 6,463,582, entitled "Dynamic Optimizing Code Object Translator for Architecture Emulation and Dynamic Optimizing Code Object Translation Method", by Lethin et al; and Letters US Patent No. 5,790,825 entitled "Method of Emulating Guest Instructions on a Host Computer by Dynamic Recompilation of Host Instructions" by Eric Traut, each of which is incorporated herein by reference in its entirety, and many others illustrate a variety of known ways to achieve emulation of an instruction format architected for a different machine for a target machine available to those of skill in the art.
[0582] In Figure 23, an example of a 5092 emulated host computer system is provided that emulates a 5000' host computer system's architecture. In the 5092 emulated host computer system, the central processor (CPU) 5091 is an emulated host processor (or virtual host processor) and comprises an emulation processor 5093 having a different native instruction set than that of the host computer's 5091 processor. 5000'. The emulated host computer system 5092 5094 has memory accessible to the emulation processor 5093. In the exemplary embodiment, the memory 5094 is divided into a host computer memory 5096 and a portion of the emulation routines 5097 portion. The 5096 host computer memory is available for 5092 emulated host computer programs according to the host computer architecture. The 5093 emulation processor executes the native instructions of an instruction set architected of a different architecture than the 5091 emulated processor, the native instructions obtained from 5097 memory emulation routines, and may access a host instruction for execution. of a program in the memory of a host computer 5096 employing one or more instruction(s) obtained in a sequence and access/decoding routine that can decode the accessed host instruction(s) to determine a native instruction execution routine to emulate the operation of the accessed host instruction. Other facilities that are defined for the host computer system's 5000' architecture can be emulated by facilities architected routines, including facilities such as general purpose registers, control registers, dynamic address translation, and I/O subsystem support and processor cache, for example. Emulation routines can also take advantage of functions available on the 5093 emulation processor (such as general registers and dynamic virtual address translation) to improve the performance of emulation routines. Special, unloaded hardware engines may also be provided to assist the processor 5093 in emulating the operation of the host computer 5000'.
[0583] The terminology used here is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the singular forms "a", "an" and "a" are intended to include the plural forms as well, unless the context clearly dictates otherwise. It will further be understood that the terms "comprises" and/or "comprising", when used herein, specify the presence of established aspects, integers, steps, operations, elements and/or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components and/or groups thereof.
[0584] The corresponding structures, materials, acts and equivalents of all means or step plus function elements in the following claims, if any, are intended to include any structure, material or act to perform the function in combination with other elements claimed as specifically claimed. The description of one or more embodiments has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiment has been chosen and described in order to better explain various aspects and practical application, and to enable others skilled in the art to understand various embodiments with various modifications as are appropriate for the particular use contemplated.

权利要求:
Claims (9)
[0001]
1. Computer system to provide diagnostic information about transaction abort, the computer system comprises: a memory; and a processor in communication with memory, wherein the computer system is configured to execute a method, said method comprising: detecting, by a processor, an abort of a transaction, the transaction comprising one or more instructions; characterized in that that determining, by the processor, whether diagnostic information is to be stored in a transaction diagnostic block (900) based on the abort; and based on the determination indicating diagnostic information to be stored, store diagnostic information (912) in the transaction diagnostic block, the diagnostic information, including an address of an instruction that was being executed when the abort was detected, the address of the instruction depending on a reason for aborting the transaction, the reason predicted in an abort code (908), and wherein: based on the abort code having a first value of one or more first values, diagnostic information, including an address of an instruction that was executed when the abort was detected; based on the abort code having a second value of one or more second values and the program exception condition not being nullable, diagnostic information, including an address of an instruction that is post-execution of instructions when the abort was detected ; and based on the abort code with a third value of one or more third values of, diagnostic information, including an address of an instruction that is earlier or later than the execution of instructions when the abort was detected.
[0002]
2. Computer system according to claim 1, characterized in that the transaction diagnostic block further comprises one or more of the following: a transaction nesting depth, a transaction abort code, a conflict token, a or more program interrupt parameters, the contents of one or more general-purpose registers at the time of the abort, and model-dependent diagnostic information.
[0003]
3. Computer system according to claim 2, characterized in that the transaction block further comprises one or more of the following: an exception access ID, an exception data code, a program interruption ID, a transaction exception ID, and a break event address.
[0004]
4. Computer system according to claim 2, characterized in that the method further comprises executing a transaction abort instruction to abort the transaction, the transaction abort instructions specifying the transaction abort code.
[0005]
5. Computer system according to claim 1, characterized in that the determination comprises determining whether an address of a valid transaction diagnostic block is provided in an instruction to start transaction, wherein based on a block address of valid transaction diagnostics is provided, the diagnostic information is stored in a transaction diagnostics block specified by the program, the instruction to start transaction starts an unconstrained transaction, the unconstrained transaction being an external operation, and where the determination is the address of a valid transaction diagnostic block is provided includes checking a base field of the instruction to start transaction of the outermost transaction, where a non-zero base field indicates a valid transaction diagnostic block address.
[0006]
6. Computer system according to claim 1, characterized in that there is a plurality of transaction diagnostic block types, and wherein the storage comprises determining where the plurality of diagnostic block types are to be stored , the determination comprising: verifying that the address of a valid transaction diagnostic block is provided in a transaction start instruction, and based on the verification indicating a valid transaction diagnostic block address, the determination indicating where the diagnostic block of transaction specified by the program should be stored; check whether the abort is due to an abort, and based on whether the abort is due to an abort, the determination indicating where an abort of the transaction diagnostic block program should be stored; checking whether the abort is due to a trap condition and based on said abort being due to the trap condition, and the determination further indicating where a trap transaction diagnostic block should be stored.
[0007]
7. Method for providing diagnostic information on transaction aborts, the method comprises: detecting, by a processor, an abort of a transaction, the transaction comprising one or more instructions; characterized by the fact that it determines, by the processor, whether the diagnostic information is to be stored in a transaction diagnostic block (900) based on the abort; and based on the determination indicating diagnostic information to be stored, store diagnostic information (912) in the transaction diagnostic block, the diagnostic information, including an address of an instruction that was executing when the abort was detected, the address of the instruction depending on a reason for aborting the transaction, the reason predicted in an abort code, and where: based on the abort code having a first value of one or more first values, diagnostic information, including an address of an instruction that was performed when the abortion was detected; based on the abort code having a second value of one or more second values and the program exception condition not being nullifying, diagnostic information, including an address of an instruction that is post-execution of instructions when the abort was detected; and based on the abort code with a third value of one or more third values of, diagnostic information, including an address of an instruction that is earlier or later than the execution of instructions when the abort was detected.
[0008]
8. Method according to claim 7, characterized in that the determination comprises determining whether a valid transaction diagnostic block address is provided in a transaction start instruction, wherein based on a diagnostic block address of valid transaction is provided, the diagnostic information is stored in a transaction diagnostic block specified by the program, the instruction to start transaction starts an unconstrained transaction, the unconstrained transaction being an external operation, and wherein the determination whether the address of a valid transaction diagnostic block is provided includes checking a base field of the instruction to start transaction of the outermost transaction, where a non-zero base field indicates a valid transaction diagnostic block address.
[0009]
9. Method according to claim 7, characterized in that there is a plurality of transaction diagnostic block types, and wherein the storage comprises determining where the plurality of diagnostic block types are to be stored, the determination comprising: verifying that the address of a valid transaction diagnostic block is provided in a transaction start instruction, and based on the verification indicating a valid transaction diagnostic block address, the determination indicating where transaction diagnostic block specified by the program must be stored; check whether the abort is due to an interrupt, and on the basis that the abort is due to an interrupt, the determination that indicates a program interrupt transaction diagnostic block must be stored; check whether the abort is due to a trap condition and based on the abort being due to the trap condition, the determination that indicates a trap transaction diagnostic block must be stored.

类似技术:

---

公开号 | 公开日 | 专利标题

---

BR112014031335B1|2022-01-04|TRANSACTIONAL DIAGNOSIS BLOCK

---

AU2013276133B2|2016-06-30|Transactional processing

---

AU2012382778B2|2016-08-18|Saving/restoring selected registers in transactional processing

---

US9983881B2|2018-05-29|Selectively controlling instruction execution in transactional processing

---

EP2862081B1|2018-10-17|Transactional execution branch indications

---

AU2012382780B2|2016-06-23|Processor assist facility

---

US10430199B2|2019-10-01|Program interruption filtering in transactional execution

---

BR112014031432B1|2021-07-27|NON TRANSACTIONAL STORAGE INSTRUCTION

---

BR112014031437B1|2021-11-09|TRANSACTIONAL EXECUTION BRANCH INDICATIONS

---

BR112014031350B1|2021-09-21|FILTERING PROGRAM INTERRUPTION IN TRANSACTIONAL RUN

---

BR112014031435B1|2021-11-09|RANDOMIZED TEST WITHIN TRANSACTIONAL EXECUTION

---

BR112014031353B1|2021-09-28|PROCESSOR ASSISTANCE FACILITY

同族专利:

---

公开号 | 公开日

---

BR112014031335A2|2017-06-27|

---

HRP20181576T1|2018-11-30|

---

CN104335181B|2017-08-15|

---

AU2012382775A1|2014-12-11|

---

AU2012382775B2|2016-09-22|

---

MX2014015290A|2015-04-10|

---

IL236253A|2018-08-30|

---

EP2834739A4|2015-07-08|

---

ZA201408077B|2016-05-25|

---

CA2874175A1|2013-12-19|

---

SI2834739T1|2018-11-30|

---

LT2834739T|2018-10-10|

---

PT2834739T|2018-11-02|

---

EP2834739B1|2018-08-22|

---

CN104335181A|2015-02-04|

---

HUE040014T2|2019-02-28|

---

US20130339806A1|2013-12-19|

---

CA2874175C|2020-04-14|

---

KR20150008392A|2015-01-22|

---

RU2571397C2|2015-12-20|

---

US8887003B2|2014-11-11|

---

JP6138249B2|2017-05-31|

---

DK2834739T3|2018-10-22|

---

HRP20181576T8|2018-12-14|

---

US8880959B2|2014-11-04|

---

TWI537718B|2016-06-11|

---

KR101599181B1|2016-03-02|

---

WO2013186600A1|2013-12-19|

---

MX338375B|2016-04-13|

---

EP2834739A1|2015-02-11|

---

RU2012148400A|2014-05-20|

---

JP2015526788A|2015-09-10|

---

IL236253D0|2015-01-29|

---

US20130339804A1|2013-12-19|

---

ES2689560T3|2018-11-14|

---

PL2834739T3|2018-12-31|

---

TW201413441A|2014-04-01|

---

SG11201407475QA|2014-12-30|

引用文献:

---

公开号 | 申请日 | 公开日 | 申请人 | 专利标题

---

---

CA1174370A|1980-05-19|1984-09-11|Hidekazu Matsumoto|Data processing unit with pipelined operands|

---

US5471591A|1990-06-29|1995-11-28|Digital Equipment Corporation|Combined write-operand queue and read-after-write dependency scoreboard|

---

GB2256514B|1991-05-21|1994-11-16|Digital Equipment Corp|Commitment ordering for guaranteeing serializability across distributed transactions|

---

US5701480A|1991-10-17|1997-12-23|Digital Equipment Corporation|Distributed multi-version commitment ordering protocols for guaranteeing serializability during transaction processing|

---

AU6629894A|1993-05-07|1994-12-12|Apple Computer, Inc.|Method for decoding guest instructions for a host computer|

---

US5925125A|1993-06-24|1999-07-20|International Business Machines Corporation|Apparatus and method for pre-verifying a computer instruction set to prevent the initiation of the execution of undefined instructions|

---

US5551013A|1994-06-03|1996-08-27|International Business Machines Corporation|Multiprocessor for hardware emulation|

---

US5748964A|1994-12-20|1998-05-05|Sun Microsystems, Inc.|Bytecode program interpreter apparatus and method with pre-verification of data type restrictions|

---

US5655100A|1995-03-31|1997-08-05|Sun Microsystems, Inc.|Transaction activation processor for controlling memory transaction execution in a packet switched cache coherent multiprocessor system|

---

WO1997013201A1|1995-10-06|1997-04-10|Advanced Micro Devices, Inc.|Unified multi-function operation scheduler for out-of-order execution in a superscalar processor|

---

US5790825A|1995-11-08|1998-08-04|Apple Computer, Inc.|Method for emulating guest instructions on a host computer through dynamic recompilation of host instructions|

---

JPH103416A|1996-06-14|1998-01-06|Canon Inc|Information processor and its method|

---

US6035313A|1997-03-24|2000-03-07|Motorola, Inc.|Memory address generator for an FFT|

---

US7076784B1|1997-10-28|2006-07-11|Microsoft Corporation|Software component execution management using context objects for tracking externally-defined intrinsic properties of executing software components within an execution environment|

---

US6000029A|1997-11-03|1999-12-07|Motorola, Inc.|Method and apparatus for affecting subsequent instruction processing in a data processor|

---

US6009261A|1997-12-16|1999-12-28|International Business Machines Corporation|Preprocessing of stored target routines for emulating incompatible instructions on a target processor|

---

US6119129A|1998-05-14|2000-09-12|Sun Microsystems, Inc.|Multi-threaded journaling in a configuration database|

---

US6308255B1|1998-05-26|2001-10-23|Advanced Micro Devices, Inc.|Symmetrical multiprocessing bus and chipset used for coprocessor support allowing non-native code to run in a system|

---

EP0992916A1|1998-10-06|2000-04-12|Texas Instruments Inc.|Digital signal processor|

---

US20020147969A1|1998-10-21|2002-10-10|Richard A. Lethin|Dynamic optimizing object code translator for architecture emulation and dynamic optimizing object code translation method|

---

US7761857B1|1999-10-13|2010-07-20|Robert Bedichek|Method for switching between interpretation and dynamic translation in a processor system based upon code sequence execution counts|

---

US6738892B1|1999-10-20|2004-05-18|Transmeta Corporation|Use of enable bits to control execution of selected instructions|

---

JP3776653B2|1999-11-24|2006-05-17|富士通株式会社|Arithmetic processing unit|

---

US6754809B1|1999-12-30|2004-06-22|Texas Instruments Incorporated|Data processing apparatus with indirect register file access|

---

US6665863B1|2000-05-31|2003-12-16|Microsoft Corporation|Data referencing within a database graph|

---

AU8316301A|2000-08-04|2002-02-18|Carr Scott Software Inc|Automatic transaction management|

---

US6671686B2|2000-11-02|2003-12-30|Guy Pardon|Decentralized, distributed internet data management|

---

US7346632B2|2001-02-22|2008-03-18|International Business Machines Corporation|Mechanism for executing nested transactions in an execution environment supporting flat transactions only|

---

US6963919B1|2001-02-28|2005-11-08|Agilent Technologies, Inc.|Method and system for improving computer network performance|

---

US6745272B2|2001-04-04|2004-06-01|Advanced Micro Devices, Inc.|System and method of increasing bandwidth for issuing ordered transactions into a distributed communication system|

---

US7185234B1|2001-04-30|2007-02-27|Mips Technologies, Inc.|Trace control from hardware and software|

---

US7305678B2|2001-05-17|2007-12-04|International Business Machines Corporation|Method and system for reducing synchronization waits when allocating sequenced identifiers in a multi-threaded server|

---

KR100625595B1|2001-05-28|2006-09-20|한국전자통신연구원|Parallel Logging Method of Transaction Processing System|

---

US7185183B1|2001-08-02|2007-02-27|Mips Technologies, Inc.|Atomic update of CPO state|

---

US20060218556A1|2001-09-28|2006-09-28|Nemirovsky Mario D|Mechanism for managing resource locking in a multi-threaded environment|

---

US7546446B2|2002-03-08|2009-06-09|Ip-First, Llc|Selective interrupt suppression|

---

US6892286B2|2002-09-30|2005-05-10|Sun Microsystems, Inc.|Shared memory multiprocessor memory model verification system and method|

---

US7103597B2|2002-10-03|2006-09-05|Mcgoveran David O|Adaptive transaction manager for complex transactions and business process|

---

US7634638B1|2002-10-22|2009-12-15|Mips Technologies, Inc.|Instruction encoding for system register bit set and clear|

---

US20040117689A1|2002-12-12|2004-06-17|International Business Machines Corporation|Method and system for diagnostic approach for fault isolation at device level on peripheral component interconnect bus|

---

US7568023B2|2002-12-24|2009-07-28|Hewlett-Packard Development Company, L.P.|Method, system, and data structure for monitoring transaction performance in a managed computer network environment|

---

US7269717B2|2003-02-13|2007-09-11|Sun Microsystems, Inc.|Method for reducing lock manipulation overhead during access to critical code sections|

---

US7398355B1|2003-02-13|2008-07-08|Sun Microsystems, Inc.|Avoiding locks by transactionally executing critical sections|

---

US7269693B2|2003-02-13|2007-09-11|Sun Microsystems, Inc.|Selectively monitoring stores to support transactional program execution|

---

US7398359B1|2003-04-30|2008-07-08|Silicon Graphics, Inc.|System and method for performing memory operations in a computing system|

---

CA2472887A1|2003-06-30|2004-12-30|Gravic, Inc.|Methods for ensuring referential integrity in multithreaded replication engines|

---

US7836450B2|2003-08-28|2010-11-16|Mips Technologies, Inc.|Symmetric multiprocessor operating system for execution on non-independent lightweight thread contexts|

---

US7269607B2|2003-09-29|2007-09-11|International Business Machines Coproartion|Method and information technology infrastructure for establishing a log point for automatic recovery of federated databases to a prior point in time|

---

US7206903B1|2004-07-20|2007-04-17|Sun Microsystems, Inc.|Method and apparatus for releasing memory locations during transactional execution|

---

US7395382B1|2004-08-10|2008-07-01|Sun Microsystems, Inc.|Hybrid software/hardware transactional memory|

---

US7401202B1|2004-09-14|2008-07-15|Azul Systems, Inc.|Memory addressing|

---

US20060064508A1|2004-09-17|2006-03-23|Ramesh Panwar|Method and system to store and retrieve message packet data in a communications network|

---

US7373554B2|2004-09-24|2008-05-13|Oracle International Corporation|Techniques for automatic software error diagnostics and correction|

---

US7856537B2|2004-09-30|2010-12-21|Intel Corporation|Hybrid hardware and software implementation of transactional memory access|

---

US7984248B2|2004-12-29|2011-07-19|Intel Corporation|Transaction based shared data operations in a multiprocessor environment|

---

US7631073B2|2005-01-27|2009-12-08|International Business Machines Corporation|Method and apparatus for exposing monitoring violations to the monitored application|

---

US20060212757A1|2005-03-15|2006-09-21|International Business Machines Corporation|Method, system, and program product for managing computer-based interruptions|

---

US7421544B1|2005-04-04|2008-09-02|Sun Microsystems, Inc.|Facilitating concurrent non-transactional execution in a transactional memory system|

---

US7496726B1|2005-04-18|2009-02-24|Sun Microsystems, Inc.|Controlling contention via transactional timers among conflicting transactions issued by processors operating in insistent or polite mode|

---

US8799882B2|2005-12-07|2014-08-05|Microsoft Corporation|Compiler support for optimizing decomposed software transactional memory operations|

---

US8117605B2|2005-12-19|2012-02-14|Oracle America, Inc.|Method and apparatus for improving transactional memory interactions by tracking object visibility|

---

US7730286B2|2005-12-30|2010-06-01|Intel Corporation|Software assisted nested hardware transactions|

---

US7810072B2|2006-01-06|2010-10-05|International Business Machines Corporation|Exception thrower|

---

US20070186056A1|2006-02-07|2007-08-09|Bratin Saha|Hardware acceleration for a software transactional memory system|

---

US20070198979A1|2006-02-22|2007-08-23|David Dice|Methods and apparatus to implement parallel transactions|

---

US8099538B2|2006-03-29|2012-01-17|Intel Corporation|Increasing functionality of a reader-writer lock|

---

US8180977B2|2006-03-30|2012-05-15|Intel Corporation|Transactional memory in out-of-order processors|

---

US7930695B2|2006-04-06|2011-04-19|Oracle America, Inc.|Method and apparatus for synchronizing threads on a processor that supports transactional memory|

---

US7636829B2|2006-05-02|2009-12-22|Intel Corporation|System and method for allocating and deallocating memory within transactional code|

---

US7707394B2|2006-05-30|2010-04-27|Arm Limited|Reducing the size of a data stream produced during instruction tracing|

---

US7849446B2|2006-06-09|2010-12-07|Oracle America, Inc.|Replay debugging|

---

US20070300013A1|2006-06-21|2007-12-27|Manabu Kitamura|Storage system having transaction monitoring capability|

---

US20080005504A1|2006-06-30|2008-01-03|Jesse Barnes|Global overflow method for virtualized transactional memory|

---

US20080016325A1|2006-07-12|2008-01-17|Laudon James P|Using windowed register file to checkpoint register state|

---

US7617421B2|2006-07-27|2009-11-10|Sun Microsystems, Inc.|Method and apparatus for reporting failure conditions during transactional execution|

---

US7865885B2|2006-09-27|2011-01-04|Intel Corporation|Using transactional memory for precise exception handling in aggressive dynamic binary optimizations|

---

US20080086516A1|2006-10-04|2008-04-10|Oracle International|Automatically changing a database system's redo transport mode to dynamically adapt to changing workload and network conditions|

---

US7669040B2|2006-12-15|2010-02-23|Sun Microsystems, Inc.|Method and apparatus for executing a long transaction|

---

JP2008165370A|2006-12-27|2008-07-17|Internatl Business Mach Corp <Ibm>|Method and device for dividing online transaction processing and executing in distributed environment|

---

US8086827B2|2006-12-28|2011-12-27|Intel Corporation|Mechanism for irrevocable transactions|

---

US7802136B2|2006-12-28|2010-09-21|Intel Corporation|Compiler technique for efficient register checkpointing to support transaction roll-back|

---

US7627743B2|2007-01-12|2009-12-01|Andes Technology Corporation|Method and circuit implementation for multiple-word transfer into/from memory subsystems|

---

GB2446831B|2007-02-22|2011-06-15|Advanced Risc Mach Ltd|Selective disabling of diagnostic functions within a data processing system|

---

US20080244544A1|2007-03-29|2008-10-02|Naveen Neelakantam|Using hardware checkpoints to support software based speculation|

---

US8332374B2|2007-04-13|2012-12-11|Oracle America, Inc.|Efficient implicit privatization of transactional memory|

---

US8117403B2|2007-05-14|2012-02-14|International Business Machines Corporation|Transactional memory system which employs thread assists using address history tables|

---

US9009452B2|2007-05-14|2015-04-14|International Business Machines Corporation|Computing system with transactional memory using millicode assists|

---

US7814378B2|2007-05-18|2010-10-12|Oracle America, Inc.|Verification of memory consistency and transactional memory|

---

US20080320282A1|2007-06-22|2008-12-25|Morris Robert P|Method And Systems For Providing Transaction Support For Executable Program Components|

---

US8266387B2|2007-06-27|2012-09-11|Microsoft Corporation|Leveraging transactional memory hardware to accelerate virtualization emulation|

---

US7779232B2|2007-08-28|2010-08-17|International Business Machines Corporation|Method and apparatus for dynamically managing instruction buffer depths for non-predicted branches|

---

US7904434B2|2007-09-14|2011-03-08|Oracle International Corporation|Framework for handling business transactions|

---

US7890472B2|2007-09-18|2011-02-15|Microsoft Corporation|Parallel nested transactions in transactional memory|

---

US20090138890A1|2007-11-21|2009-05-28|Arm Limited|Contention management for a hardware transactional memory|

---

CN101170747A|2007-11-30|2008-04-30|中兴通讯股份有限公司|Relay state adjusting method and device|

---

US8195898B2|2007-12-27|2012-06-05|Intel Corporation|Hybrid transactions for low-overhead speculative parallelization|

---

US8706982B2|2007-12-30|2014-04-22|Intel Corporation|Mechanisms for strong atomicity in a transactional memory system|

---

US8140497B2|2007-12-31|2012-03-20|Oracle America, Inc.|System and method for implementing nonblocking zero-indirection transactional memory|

---

US7966459B2|2007-12-31|2011-06-21|Oracle America, Inc.|System and method for supporting phased transactional memory modes|

---

US8041900B2|2008-01-15|2011-10-18|Oracle America, Inc.|Method and apparatus for improving transactional memory commit latency|

---

US8176279B2|2008-02-25|2012-05-08|International Business Machines Corporation|Managing use of storage by multiple pageable guests of a computing environment|

---

US8161273B2|2008-02-26|2012-04-17|Oracle America, Inc.|Method and apparatus for programmatically rewinding a register inside a transaction|

---

US8688628B2|2008-02-29|2014-04-01|Red Hat, Inc.|Nested queued transaction manager|

---

US20090260011A1|2008-04-14|2009-10-15|Microsoft Corporation|Command line transactions|

---

JP5385545B2|2008-04-17|2014-01-08|インターナショナル・ビジネス・マシーンズ・コーポレーション|Apparatus and method for controlling execution of transaction|

---

US9367363B2|2008-05-12|2016-06-14|Oracle America, Inc.|System and method for integrating best effort hardware mechanisms for supporting transactional memory|

---

US7996686B2|2008-07-07|2011-08-09|International Business Machines Corporation|Branch trace methodology|

---

WO2010014200A1|2008-07-28|2010-02-04|Advanced Micro Devices, Inc.|Virtualizable advanced synchronization facility|

---

US8191046B2|2008-10-06|2012-05-29|Microsoft Corporation|Checking transactional memory implementations|

---

JP4702962B2|2008-11-12|2011-06-15|インターナショナル・ビジネス・マシーンズ・コーポレーション|MEMORY CONTROL DEVICE, PROGRAM, AND METHOD|

---

US8789057B2|2008-12-03|2014-07-22|Oracle America, Inc.|System and method for reducing serialization in transactional memory using gang release of blocked threads|

---

US20100153776A1|2008-12-12|2010-06-17|Sun Microsystems, Inc.|Using safepoints to provide precise exception semantics for a virtual machine|

---

US9274855B2|2008-12-24|2016-03-01|Intel Corporation|Optimization for safe elimination of weak atomicity overhead|

---

US10210018B2|2008-12-24|2019-02-19|Intel Corporation|Optimizing quiescence in a software transactional memory system|

---

US9785462B2|2008-12-30|2017-10-10|Intel Corporation|Registering a user-handler in hardware for transactional memory event handling|

---

US8799582B2|2008-12-30|2014-08-05|Intel Corporation|Extending cache coherency protocols to support locally buffered data|

---

CN101819518B|2009-02-26|2013-09-11|国际商业机器公司|Method and device for quickly saving context in transactional memory|

---

US8266107B2|2009-03-11|2012-09-11|International Business Machines Corporation|Method for mirroring a log file by threshold driven synchronization|

---

US9940138B2|2009-04-08|2018-04-10|Intel Corporation|Utilization of register checkpointing mechanism with pointer swapping to resolve multithreading mis-speculations|

---

US8973004B2|2009-06-26|2015-03-03|Oracle America, Inc.|Transactional locking with read-write locks in transactional memory systems|

---

US8489864B2|2009-06-26|2013-07-16|Microsoft Corporation|Performing escape actions in transactions|

---

US8281185B2|2009-06-30|2012-10-02|Oracle America, Inc.|Advice-based feedback for transactional execution|

---

US8229907B2|2009-06-30|2012-07-24|Microsoft Corporation|Hardware accelerated transactional memory system with open nested transactions|

---

US8688964B2|2009-07-20|2014-04-01|Microchip Technology Incorporated|Programmable exception processing latency|

---

GB2472620B|2009-08-12|2016-05-18|Cloudtran Inc|Distributed transaction processing|

---

US8392694B2|2009-09-15|2013-03-05|International Business Machines Corporation|System and method for software initiated checkpoint operations|

---

US8327188B2|2009-11-13|2012-12-04|Oracle America, Inc.|Hardware transactional memory acceleration through multiple failure recovery|

---

US8316194B2|2009-12-15|2012-11-20|Intel Corporation|Mechanisms to accelerate transactions using buffered stores|

---

US8290991B2|2009-12-15|2012-10-16|Juniper Networks, Inc.|Atomic deletion of database data categories|

---

US8095824B2|2009-12-15|2012-01-10|Intel Corporation|Performing mode switching in an unbounded transactional memory system|

---

US9092253B2|2009-12-15|2015-07-28|Microsoft Technology Licensing, Llc|Instrumentation of hardware assisted transactional memory system|

---

US8301849B2|2009-12-23|2012-10-30|Intel Corporation|Transactional memory in out-of-order processors with XABORT having immediate argument|

---

US20110208921A1|2010-02-19|2011-08-25|Pohlack Martin T|Inverted default semantics for in-speculative-region memory accesses|

---

US8739164B2|2010-02-24|2014-05-27|Advanced Micro Devices, Inc.|Automatic suspend atomic hardware transactional memory in response to detecting an implicit suspend condition and resume thereof|

---

US8438568B2|2010-02-24|2013-05-07|International Business Machines Corporation|Speculative thread execution with hardware transactional memory|

---

US8464261B2|2010-03-31|2013-06-11|Oracle International Corporation|System and method for executing a transaction using parallel co-transactions|

---

US8631223B2|2010-05-12|2014-01-14|International Business Machines Corporation|Register file supporting transactional processing|

---

US9626187B2|2010-05-27|2017-04-18|International Business Machines Corporation|Transactional memory system supporting unbroken suspended execution|

---

US20110302143A1|2010-06-02|2011-12-08|Microsoft Corporation|Multi-version concurrency with ordered timestamps|

---

US9880848B2|2010-06-11|2018-01-30|Advanced Micro Devices, Inc.|Processor support for hardware transactional memory|

---

US8560816B2|2010-06-30|2013-10-15|Oracle International Corporation|System and method for performing incremental register checkpointing in transactional memory|

---

US8479053B2|2010-07-28|2013-07-02|Intel Corporation|Processor with last branch record register storing transaction indicator|

---

US8561033B2|2010-07-30|2013-10-15|International Business Machines Corporation|Selective branch-triggered trace generation apparatus and method|

---

US8549504B2|2010-09-25|2013-10-01|Intel Corporation|Apparatus, method, and system for providing a decision mechanism for conditional commits in an atomic region|

---

US8442962B2|2010-12-28|2013-05-14|Sap Ag|Distributed transaction management using two-phase commit optimization|US9361115B2|2012-06-15|2016-06-07|International Business Machines Corporation|Saving/restoring selected registers in transactional processing|

---

US9448796B2|2012-06-15|2016-09-20|International Business Machines Corporation|Restricted instructions in transactional execution|

---

US20130339680A1|2012-06-15|2013-12-19|International Business Machines Corporation|Nontransactional store instruction|

---

US9740549B2|2012-06-15|2017-08-22|International Business Machines Corporation|Facilitating transaction completion subsequent to repeated aborts of the transaction|

---

US9436477B2|2012-06-15|2016-09-06|International Business Machines Corporation|Transaction abort instruction|

---

US9772854B2|2012-06-15|2017-09-26|International Business Machines Corporation|Selectively controlling instruction execution in transactional processing|

---

US9348642B2|2012-06-15|2016-05-24|International Business Machines Corporation|Transaction begin/end instructions|

---

US9336046B2|2012-06-15|2016-05-10|International Business Machines Corporation|Transaction abort processing|

---

US9384004B2|2012-06-15|2016-07-05|International Business Machines Corporation|Randomized testing within transactional execution|

---

US10437602B2|2012-06-15|2019-10-08|International Business Machines Corporation|Program interruption filtering in transactional execution|

---

CN105723348B|2013-12-17|2019-02-15|英特尔公司|Unauthorized memory modification and access are detected using transactional memory|

---

US10152540B2|2014-10-10|2018-12-11|Qualcomm Incorporated|Linking thumbnail of image to web page|

---

US10725685B2|2017-01-19|2020-07-28|International Business Machines Corporation|Load logical and shift guarded instruction|

---

US10496311B2|2017-01-19|2019-12-03|International Business Machines Corporation|Run-time instrumentation of guarded storage event processing|

---

US10579377B2|2017-01-19|2020-03-03|International Business Machines Corporation|Guarded storage event handling during transactional execution|

---

US10732858B2|2017-01-19|2020-08-04|International Business Machines Corporation|Loading and storing controls regulating the operation of a guarded storage facility|

---

US10496292B2|2017-01-19|2019-12-03|International Business Machines Corporation|Saving/restoring guarded storage controls in a virtualized environment|

---

US10452288B2|2017-01-19|2019-10-22|International Business Machines Corporation|Identifying processor attributes based on detecting a guarded storage event|

---

US10831509B2|2017-02-23|2020-11-10|Ab Initio Technology Llc|Dynamic execution of parameterized applications for the processing of keyed network data streams|

法律状态:
2018-12-04| B06F| Objections, documents and/or translations needed after an examination request according [chapter 6.6 patent gazette]|

---

2019-12-10| B06U| Preliminary requirement: requests with searches performed by other patent offices: procedure suspended [chapter 6.21 patent gazette]|

---

2021-08-03| B06A| Patent application procedure suspended [chapter 6.1 patent gazette]|

---

2021-11-30| B09A| Decision: intention to grant [chapter 9.1 patent gazette]|

---

2022-01-04| B16A| Patent or certificate of addition of invention granted [chapter 16.1 patent gazette]|Free format text: PRAZO DE VALIDADE: 20 (VINTE) ANOS CONTADOS A PARTIR DE 22/11/2012, OBSERVADAS AS CONDICOES LEGAIS. |

优先权:

---

申请号 | 申请日 | 专利标题

---

US13/524916|2012-06-15|

---

US13/524,916|US8880959B2|2012-06-15|2012-06-15|Transaction diagnostic block|

---

PCT/IB2012/056622|WO2013186600A1|2012-06-15|2012-11-22|Transaction diagnostic block|

---